[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by kenneth westelinck (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
kenneth westelinck commented on JBRULES-3675:
---------------------------------------------
Well, that is not really possible. We have a fairly complex application with a large amount of rules being fired. And I am not allowed to send any code. However, we can reproduce it fairly easy on our side. So maybe you can add some more logging and I am willing to post you the output. Does this sound feasible?
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
Mario Fusco commented on JBRULES-3675:
--------------------------------------
Could you post a test case or a small project that could allow me to reproduce this issue?
Thanks for your help,
Mario
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6333) Add an id xml attribute to resource-adpter containing DMR resource name
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-6333?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen updated AS7-6333:
---------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.2.0.CR1)
Priority: Critical (was: Major)
> Add an id xml attribute to resource-adpter containing DMR resource name
> -----------------------------------------------------------------------
>
> Key: AS7-6333
> URL: https://issues.jboss.org/browse/AS7-6333
> Project: Application Server 7
> Issue Type: Task
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> <xs:attribute name="id" type="xs:token" use="optional"><xs:annotation><xs:documentation>[
> An unique identifier for the resource adapter
> </xs:documentation></xs:annotation></xs:attribute>
> In case it is null resource name in DMR have to be generated (as now) and marshall in this attribute.
> This way also generated name will be consistent after a server reload
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6393) Update commons-codec version to 1.6
by Josef Cacek (JIRA)
Josef Cacek created AS7-6393:
--------------------------------
Summary: Update commons-codec version to 1.6
Key: AS7-6393
URL: https://issues.jboss.org/browse/AS7-6393
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Reporter: Josef Cacek
Assignee: Josef Cacek
Apache HttpClient (4.2.1) library depends on commons-codec version 1.6, but we use only a version 1.4 now which is not fully compatible - e.g. changed behavior of the default constructor in Base64 class (chunked/not-chunked).
The problem is then in HttpClient's SPNEGO authentication.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by kenneth westelinck (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
kenneth westelinck commented on JBRULES-3675:
---------------------------------------------
No, that does not solve the issue. We encountered it again, even after synchronizing.
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6392) standalone.sh / domain.sh does not support overriding jboss.server.base.dir, log and config dir in CYGWIN
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/AS7-6392?page=com.atlassian.jira.plugin.s... ]
Tom Fonteyne updated AS7-6392:
------------------------------
Steps to Reproduce:
run a commmand like this for example:
standalone.sh -Djboss.server.base.dir=/cygdrive/c/jboss/eap/test
JBoss will not use the "test" dir
The test should allow both linux and cygwin
was:
run a commmane like this for example:
standalone.sh -Djboss.server.base.dir=/cygdrive/c/jboss/eap/test
JBoss will not use the "test" dir
The test allow both linux and cygwin
> standalone.sh / domain.sh does not support overriding jboss.server.base.dir, log and config dir in CYGWIN
> ---------------------------------------------------------------------------------------------------------
>
> Key: AS7-6392
> URL: https://issues.jboss.org/browse/AS7-6392
> Project: Application Server 7
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> There is a check on linux, so a cygwin system will not execute this block:
> if $linux; then
> # consolidate the server and command line opts
> CONSOLIDATED_OPTS="$JAVA_OPTS $SERVER_OPTS"
> # process the standalone options
> for var in $CONSOLIDATED_OPTS
> do
> case $var in
> -Djboss.server.base.dir=*)
> JBOSS_BASE_DIR=`readlink -m ${var#*=}`
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6392) standalone.sh / domain.sh does not support overriding jboss.server.base.dir, log and config dir in CYGWIN
by Tom Fonteyne (JIRA)
Tom Fonteyne created AS7-6392:
---------------------------------
Summary: standalone.sh / domain.sh does not support overriding jboss.server.base.dir, log and config dir in CYGWIN
Key: AS7-6392
URL: https://issues.jboss.org/browse/AS7-6392
Project: Application Server 7
Issue Type: Bug
Components: Scripts
Affects Versions: 7.1.3.Final (EAP)
Reporter: Tom Fonteyne
Assignee: Brian Stansberry
There is a check on linux, so a cygwin system will not execute this block:
if $linux; then
# consolidate the server and command line opts
CONSOLIDATED_OPTS="$JAVA_OPTS $SERVER_OPTS"
# process the standalone options
for var in $CONSOLIDATED_OPTS
do
case $var in
-Djboss.server.base.dir=*)
JBOSS_BASE_DIR=`readlink -m ${var#*=}`
...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBRULES-3681) NullPointerException in ConditionAnalyzer
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3681?page=com.atlassian.jira.plug... ]
Mario Fusco commented on JBRULES-3681:
--------------------------------------
Constraint jitting has been introduced since 5.4.x so I don't see how you could have experienced this problem on the 5.3.x.
That said I'd need to reproduce the problem you're experiencing in order to fix it. Can you send a test case or at least give me a bit more infos no how to reproduce it?
Could you also try the 5.5.0.Final and check if you have the same problem also there?
Thanks,
Mario
> NullPointerException in ConditionAnalyzer
> -----------------------------------------
>
> Key: JBRULES-3681
> URL: https://issues.jboss.org/browse/JBRULES-3681
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core (expert)
> Affects Versions: 5.4.0.Final, 5.5.0.CR1
> Environment: Windows XP
> Java 1.6.0_24 (build 1.6.0_24-b07), Hotspot Client VM (build 19.1-b02, mixed mode, sharing)
> Reporter: Paul Evans
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> I'm using Drools in a relatively vanilla fashion -- not doing anything fancy; no custom DSLs or whatnot. I have a JUnit test case that invokes a set of rules. When the test case is run individually, it passes just fine. However, when the test case is run within a larger test suite (i.e., with other test cases), the test fails. When running the test suite, I do see an exception being thrown by Drools:
> Exception in thread "Thread-1" java.lang.NullPointerException
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:116)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:102)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:73)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:214)
> at org.drools.rule.constraint.MvelConstraint.access$000(MvelConstraint.java:41)
> at org.drools.rule.constraint.MvelConstraint$1.run(MvelConstraint.java:201)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> I have experienced this behavior sporadically with other test cases as well. FYI, there is no *shared* data being consumed between test cases. Also, we are using stateless knowledge sessions. Each individual test case will get its own fresh stateless knowledge session instance.
> Is there a way to disable JIT'ing within Drools? (as this seems to be a JIT-related issue). FYI, I experience this issue in the following Drools releases: 5.3.3.Final, 5.4.0.Final and 5.5.0.CR1.
> -Paul
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months