[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:
--------------------------------------
At the moment I am not able to reproduce this issue, but the solution you're suggesting seems reasonable to me.
Can you confirm that synchronizing that loadClass method is enough to definitively solve the problem for you?
> 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-3684) MVEL is having issues resolving a generic member in a concrete type
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3684?page=com.atlassian.jira.plug... ]
Mario Fusco resolved JBRULES-3684.
----------------------------------
Resolution: Done
Fixed with mvel 2.1.4
> MVEL is having issues resolving a generic member in a concrete type
> -------------------------------------------------------------------
>
> Key: JBRULES-3684
> URL: https://issues.jboss.org/browse/JBRULES-3684
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler
> Affects Versions: 5.5.0.CR1
> Reporter: Justin Holmes
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 6.0.0.Alpha1
>
>
> Not sure if this is related to Drools use of MVEL or MVEl itself...
> I have 2 classes:
> public abstract class AbstractBase<T> {
> protected T foo;
> public T getFoo() {
> return foo;
> }
> }
> public class StringConcrete extends AbstractBase<String> {
> public StringConcrete() {
> this.foo = new String();
> }
> }
> The following rule fails in MVEL dialect, but passes in Java dialect.
> rule "test"
> dialect "mvel"
> when
> $S : StringConcrete()
> then
> System.out.println( $S.getFoo().concat("this works with java dialect") );
> end
--
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-3723) 'IDEOGRAPHIC SPACE' (U+3000) in DSL fails
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3723?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated JBRULES-3723:
---------------------------------------
Git Pull Request: https://github.com/droolsjbpm/drools/pull/173
Sent a pull request for test case.
As a fix, I think adding '\u3000' to DSLMap.g and generating antlr artifacts would be fine but not 100% sure.
> 'IDEOGRAPHIC SPACE' (U+3000) in DSL fails
> -----------------------------------------
>
> Key: JBRULES-3723
> URL: https://issues.jboss.org/browse/JBRULES-3723
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler-DSL
> Affects Versions: 5.5.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mark Proctor
>
> When DSL contains ' ' (='IDEOGRAPHIC SPACE' (U+3000)), DSLMapLexer fails with "DSL lexer error" (Internally, it's a NoViableAltException). IDEOGRAPHIC SPACE is commonly used in Japan so please allow it to use. It doesn't mean that I want to use IDEOGRAPHIC SPACE as an alternative to ASCII whitespace. Just to use it as same as usual unicode characters.
--
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-3723) 'IDEOGRAPHIC SPACE' (U+3000) in DSL fails
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created JBRULES-3723:
------------------------------------------
Summary: 'IDEOGRAPHIC SPACE' (U+3000) in DSL fails
Key: JBRULES-3723
URL: https://issues.jboss.org/browse/JBRULES-3723
Project: JBRULES
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler-DSL
Affects Versions: 5.5.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mark Proctor
When DSL contains ' ' (='IDEOGRAPHIC SPACE' (U+3000)), DSLMapLexer fails with "DSL lexer error" (Internally, it's a NoViableAltException). IDEOGRAPHIC SPACE is commonly used in Japan so please allow it to use. It doesn't mean that I want to use IDEOGRAPHIC SPACE as an alternative to ASCII whitespace. Just to use it as same as usual unicode characters.
--
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] (JGRP-1571) Race condition in tcpgossip discovery
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1571?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1571:
---------------------------
Fix Version/s: 3.3
> Race condition in tcpgossip discovery
> -------------------------------------
>
> Key: JGRP-1571
> URL: https://issues.jboss.org/browse/JGRP-1571
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.1
> Reporter: Ramky Kandula
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> We are observing a race condition in TCPGOSSIP based discovery.
> A is gossip router and B is a node connecting to gossip router.
> Timer-1 on B starts connecting, does ping.
> Timer-2 on B starts reconnecting
> A sees this new connection and closes the old one from Timer-1 from B.
> Timer-2 on B does ping
> Timer-1 on B tries to do gossip_get and encounters broken pipe as the socket
> is closed.
> This process goes on forever.
> Logs from Gossip Router A
> =========================
> 2012-12-14 13:20:47,687 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
> Accepted connection, socket is
> Socket[addr=/192.168.1.11,port=21009,localport=12001]
> 2012-12-14 13:20:47,687 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
> receive loop
> 2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
> CONNECT(group=TestCluster, addr=dd-ace1-20957,
> logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
> /192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
> addr[dd-ace1-20957]. Closing old connection ...
> 2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] connection handshake completed, added
> dd-ace1-20957 to group TestCluster
> 2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
> addr=dd-ace1-20957, logical_name=dd-ace1-20957,
> physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] received PING(group=null, addr=null)
> 2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] processed PING(group=null, addr=null)
> 2012-12-14 13:20:53,735 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] received CONNECT(group=TestCluster,
> addr=dd-ace1-20957, logical_name=dd-ace1-20957,
> physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
> /192.168.1.11, logical_addrs: dd-ace1-20957]] for addr[dd-ace1-20957]. Closing
> old connection ...
> 2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] is being closed
> 2012-12-14 13:20:53,838 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957, dd-ace1-20957] connection handshake completed,
> added dd-ace1-20957 to group TestCluster
> 2012-12-14 13:20:53,838 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957, dd-ace1-20957] processed
> CONNECT(group=TestCluster, addr=dd-ace1-20957,
> logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:21:04,023 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
> Accepted connection, socket is
> Socket[addr=/192.168.1.11,port=37357,localport=12001]
> 2012-12-14 13:21:04,023 DEBUG [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
> receive loop
> 2012-12-14 13:21:04,085 TRACE [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
> CONNECT(group=TestCluster, addr=dd-ace1-20957,
> logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:21:04,085 DEBUG [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
> /192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
> addr[dd-ace1-20957]. Closing old connection ...
> 2012-12-14 13:21:04,086 DEBUG [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] connection handshake completed, added
> dd-ace1-20957 to group TestCluster
> 2012-12-14 13:21:04,086 TRACE [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
> addr=dd-ace1-20957, logical_name=dd-ace1-20957,
> physical_addrs=192.168.1.11:7800)
> Logs from Gossip Client B
> =========================
> 2012-12-14 13:20:47,687 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
> Accepted connection, socket is
> Socket[addr=/192.168.1.11,port=21009,localport=12001]
> 2012-12-14 13:20:47,687 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
> receive loop
> 2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
> CONNECT(group=TestCluster, addr=dd-ace1-20957,
> logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
> /192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
> addr[dd-ace1-20957]. Closing old connection ...
> 2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] connection handshake completed, added
> dd-ace1-20957 to group TestCluster
> 2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
> addr=dd-ace1-20957, logical_name=dd-ace1-20957,
> physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] received PING(group=null, addr=null)
> 2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] processed PING(group=null, addr=null)
> 2012-12-14 13:20:53,735 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] received CONNECT(group=TestCluster,
> addr=dd-ace1-20957, logical_name=dd-ace1-20957,
> physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
> /192.168.1.11, logical_addrs: dd-ace1-20957]] for addr[dd-ace1-20957]. Closing
> old connection ...
> 2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] is being closed
> 2012-12-14 13:20:53,838 DEBUG [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957, dd-ace1-20957] connection handshake completed,
> added dd-ace1-20957 to group TestCluster
> 2012-12-14 13:20:53,838 TRACE [gossip-handlers--9882][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957, dd-ace1-20957] processed
> CONNECT(group=TestCluster, addr=dd-ace1-20957,
> logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:21:04,023 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
> Accepted connection, socket is
> Socket[addr=/192.168.1.11,port=37357,localport=12001]
> 2012-12-14 13:21:04,023 DEBUG [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
> receive loop
> 2012-12-14 13:21:04,085 TRACE [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
> CONNECT(group=TestCluster, addr=dd-ace1-20957,
> logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
> 2012-12-14 13:21:04,085 DEBUG [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
> /192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
> addr[dd-ace1-20957]. Closing old connection ...
> 2012-12-14 13:21:04,086 DEBUG [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] connection handshake completed, added
> dd-ace1-20957 to group TestCluster
> 2012-12-14 13:21:04,086 TRACE [gossip-handlers--9881][]
> org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
> logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
> addr=dd-ace1-20957, logical_name=dd-ace1-20957,
> physical_addrs=192.168.1.11:7800)
--
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