[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Shashank Agarwal (JIRA)
[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ]
Shashank Agarwal commented on DROOLS-618:
-----------------------------------------
Upgrade to drools 6.x is difficult as drools have changed the packages names.
Also there are some bugs in drools 6.x that accumulate and collect does not function properly in 6.x series so we are uncertain.
Also more importantly, is there a reasoning
why Deadlock will NOT happen in drools 6.x ?
why deadlock happens in 5.6.x ?
> Thread deadlock on org.drools.util.CompositeClassLoader
> -------------------------------------------------------
>
> Key: DROOLS-618
> URL: https://issues.jboss.org/browse/DROOLS-618
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: drools expert
> Reporter: Shashank Agarwal
> Assignee: Mark Proctor
> Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt
>
>
> Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
> Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
> Name: http-54350-Processor15
> State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
> Name: http-54350-Processor18
> State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
> Name: http-54350-Processor20
> State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
> We do not have definite threads to re-produce the issue.
> But deadlocks are happening repeatedly on our production.
> Regarding out environment details:
> 1. We have windows box on which application runs.
> 2. The rules used are kept in .drl and .xls formats
> 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
> 4. Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-618:
---------------------------------------
Unfortunately Drools 5.x and its CompositeClassLoader were never designed, and thus not guaranteed to be completely thread-safe.
Any chance you can upgrade to the 6.x series?
> Thread deadlock on org.drools.util.CompositeClassLoader
> -------------------------------------------------------
>
> Key: DROOLS-618
> URL: https://issues.jboss.org/browse/DROOLS-618
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: drools expert
> Reporter: Shashank Agarwal
> Assignee: Mark Proctor
> Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt
>
>
> Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
> Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
> Name: http-54350-Processor15
> State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
> Name: http-54350-Processor18
> State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
> Name: http-54350-Processor20
> State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
> We do not have definite threads to re-produce the issue.
> But deadlocks are happening repeatedly on our production.
> Regarding out environment details:
> 1. We have windows box on which application runs.
> 2. The rules used are kept in .drl and .xls formats
> 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
> 4. Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JBEE-157) Improper exception handling in org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow()
by David Lloyd (JIRA)
David Lloyd created JBEE-157:
--------------------------------
Summary: Improper exception handling in org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow()
Key: JBEE-157
URL: https://issues.jboss.org/browse/JBEE-157
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-rmi-api
Reporter: David Lloyd
Assignee: Shelly McGowan
org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow() has a {{catch (Exception error)}} block in it which wraps all exceptions in a {{ClassCastException}}. However, there should be a second catch block which catches {{RuntimeException}} and rethrows them verbatim, in order to avoid confusing incorrect error messages.
In particular, you can get a {{ClassCastException}} whose cause is another {{ClassCastException}}.
Problem found in 1.0.4.Final; no version for this exists in the JIRA schema however.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years