[JBoss JIRA] (WFLY-9949) Wildfly 12 : jboss-cli.sh in infinite loop
by Gaétan QUENTIN (JIRA)
Gaétan QUENTIN created WFLY-9949:
------------------------------------
Summary: Wildfly 12 : jboss-cli.sh in infinite loop
Key: WFLY-9949
URL: https://issues.jboss.org/browse/WFLY-9949
Project: WildFly
Issue Type: Bug
Components: CLI
Affects Versions: 12.0.0.Final
Environment: ubuntu 16.06 lxd container
java version "1.8.0_161" oracle
v12 migrated from v11
Reporter: Gaétan QUENTIN
Assignee: Jean-Francois Denise
Attachments: jboss-cli.25300
i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
wildfly@java2:/opt/Wildfly$ ls -la
drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
my wildfly management console is on 172.20.12.192.
v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
with wildfly-current link on -> wildfly-11.0.0.Final:
this works perfectly:
(cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
with wildfly-current -> wildfly-12.0.0.Final:
this go in infinite loop until crash :
(cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
output:
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
''[standalone@172.20.12.192:9990'' is not a valid operation name.
[standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
[standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9020) Wildfly 10 - JPA Entity deserialization problem on @Transient field
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-9020?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-9020:
---------------------------------------------
I believe this issue can be closed.
The same issue could happen on weblogic with its corba libraries.
The JDK seems to a have problem with proper de-serialization of treemaps.
The issue was resolved by stopping to use treemap on the entity and instead using hashamp.
Thanks.
> Wildfly 10 - JPA Entity deserialization problem on @Transient field
> -------------------------------------------------------------------
>
> Key: WFLY-9020
> URL: https://issues.jboss.org/browse/WFLY-9020
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 10.0.0.Final
> Environment: Windows 7, Eclipselink 2.6.4 integration, Widlfly 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Priority: Minor
>
> In Wildfly 10,
> We have some system tests that sporadically fail when the client of the application loads an entity, connected to other sub-entities, where one of these sub-entities has a @Transient field.
> In Particular, we have an entity Attributes that has a field of the form:
> {panel}
> @Transient
> private Map<String, String> attributeMap = new TreeMap<String, String>();
> {panel}
> The root cause of the deserialization problem is of the form:
> {panel}
> Caused by: an exception which occurred:
> in object of type java.util.TreeMap
> in field attributeMap
> in object of type basepackage.entity.Attributes
> in field attributes
> in object of type basepackage.entity.SubEntityB
> in element at index [0] of size [1]
> in field delegate
> in object of type org.eclipse.persistence.internal.indirection.jdk8.IndirectList
> in field loadUnits
> in object of type basepackage.entity.ParentEntityA
> {panel}
> The de-serialization execution stack looks as follows:
> {panel}
> Caused by: java.io.OptionalDataException
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:147)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2567)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2583)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2508)
> at java.util.TreeMap.readObject(TreeMap.java:2454)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:776)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:675)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:104)
> {panel}
> We are using the following cliean library:
> {panel}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-client-all</artifactId>
> <version>10.0.0.Final</version>
> <scope>test</scope>
> <optional>true</optional>
> <exclusions>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-commons</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-core-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-jms-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-hqclient-protocol</artifactId>
> </exclusion>
> <exclusion>
> <groupId> org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {panel}
> Currently no sample application exists to reproduce the issue.
> On weblogic the deserialization process goes without incident.
> Could the @Transient annotation and the eventual (empty map vs popuated attribtues map) play a role on this issue?
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2361) Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle
by Sidi Mohamed EL AATIFI (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2361?page=com.atlassian.jira.plugi... ]
Sidi Mohamed EL AATIFI updated DROOLS-2361:
-------------------------------------------
Description:
This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
in my case 40% of CPU usage was to
_java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
UPDATE:
One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
and provide identityHashCode backed by native (fast) hashCode
was:
This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
in my case 40% of CPU usage was to
_ java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
UPDATE:
One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
and provide identityHashCode backed by native (fast) hashCode
> Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle
> --------------------------------------------------------------------------
>
> Key: DROOLS-2361
> URL: https://issues.jboss.org/browse/DROOLS-2361
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.6.0.Final
> Reporter: Sidi Mohamed EL AATIFI
> Assignee: Mario Fusco
> Labels: performance
>
> This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
> It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
> in my case 40% of CPU usage was to
> _java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
> UPDATE:
> One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
> and provide identityHashCode backed by native (fast) hashCode
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2361) Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle
by Sidi Mohamed EL AATIFI (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2361?page=com.atlassian.jira.plugi... ]
Sidi Mohamed EL AATIFI updated DROOLS-2361:
-------------------------------------------
Description:
This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
in my case 40% of CPU usage was to
_ java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
UPDATE:
One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
and provide identityHashCode backed by native (fast) hashCode
was:
This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
in my case 40% of CPU usage was to
_ java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
> Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle
> --------------------------------------------------------------------------
>
> Key: DROOLS-2361
> URL: https://issues.jboss.org/browse/DROOLS-2361
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.6.0.Final
> Reporter: Sidi Mohamed EL AATIFI
> Assignee: Mario Fusco
> Labels: performance
>
> This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
> It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
> in my case 40% of CPU usage was to
> _ java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
> UPDATE:
> One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
> and provide identityHashCode backed by native (fast) hashCode
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2361) Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle
by Sidi Mohamed EL AATIFI (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2361?page=com.atlassian.jira.plugi... ]
Sidi Mohamed EL AATIFI updated DROOLS-2361:
-------------------------------------------
Description:
This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
in my case 40% of CPU usage was to
_ java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
was:
This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
in my case 40% of CPU usage was to
_ java.lang.System.identityHashCode_
Please consider to propose a workaround if possible
> Use of System.identityHashCode in org.drools.core.common.DefaultFactHandle
> --------------------------------------------------------------------------
>
> Key: DROOLS-2361
> URL: https://issues.jboss.org/browse/DROOLS-2361
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.6.0.Final
> Reporter: Sidi Mohamed EL AATIFI
> Assignee: Mario Fusco
> Labels: performance
>
> This is a JVM https://bugs.openjdk.java.net/browse/JDK-6378256 bug has been fixed in JDK 9
> It's not a bug in Drools but will be affected severely if using Drools for serious workloads.
> in my case 40% of CPU usage was to
> _ java.lang.System.identityHashCode_ used by org.drools.core.common.DefaultFactHandle#determineIdentityHashCode
> One possible solution is to introduce new (optional) interface for identityHashCode that can be implemented by user facts and internal facts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3411) CLI operation completion issues
by Marek Marusic (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3411?page=com.atlassian.jira.plugi... ]
Marek Marusic commented on WFCORE-3411:
---------------------------------------
I found out that there is another issue with completion.
When I try:
{code}
:reload-servers(blocking=false<TAB>
{code}
it returns candidates "," and ")" which I believe is correct, since there is a second possible property "start-mode".
However, with negated value the separator is not offered:
{code}
:reload-servers(!blocking <TAB> ==> :reload-servers(!blocking)
{code}
it completes ")" and does not offer the separator ",".
[~jdenise] I have prepared a fix for this as well, should I create a new WFCORE issue and create a separate PR for it or propose the fix in the same PR which I will do for WFCORE-3411 ?
Thank You very much for the answer.
> CLI operation completion issues
> -------------------------------
>
> Key: WFCORE-3411
> URL: https://issues.jboss.org/browse/WFCORE-3411
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Marek Marusic
>
> :read-resource(proxies=<TAB> ==> :read-resource(proxies=alse should be :read-resource(proxies=false
> :reload-servers(start-mode=normal,!blocking ==> gives nothing, should be :reload-servers(start-mode=normal,!blocking)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months