[
https://jira.jboss.org/jira/browse/JBRULES-1876?page=com.atlassian.jira.p...
]
Michael Neale commented on JBRULES-1876:
----------------------------------------
Any chance you could try and reproduce this with 5 as well?
Deadlock when RuleAgent thread refreshes rules while another thread
creates a statefulSession
---------------------------------------------------------------------------------------------
Key: JBRULES-1876
URL:
https://jira.jboss.org/jira/browse/JBRULES-1876
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-core
Affects Versions: 4.0.7
Environment: Windows XP SP3
Sun JRE 1.5.0_14
Reporter: Shahad Ahmed
Assignee: Michael Neale
I believe I have discovered a deadlock that can occur in drools 4.0.7 if the RuleAgent
refreshes its associated RuleBase whilst a new stateful session is being created on the
RuleBase by another thread.
The thread dump below shows the deadlock where the two thread "Timer-15" and
"DataSource(com.acme.Source)-2" are deadlocked. Thread "Timer-15" is
the timer thread created by the RuleAgent rule refresh mechanism to check if the rules
files have changed, and to refresh the rules when a change is found. If it finds changes
to the rules then it obtains a lock (<0x189a8d88> (a java.util.HashMap)) and
proceeds to removes the old version of the changed package from the RuleBase. To do this
it needs to obtain another lock (<0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase))
before it can call removeRule.
However, in another thread "DataSource(com.acme.Source)-2" a new stateful
session is being created on the same RuleBase. This has already obtained the lock
(<0x189a8d88> (a java.util.HashMap)) that the Timer thread is waiting for, and is
itself waiting for the another lock <0x189a2ba0> (a
org.drools.reteoo.ReteooRuleBase) that the Timer thread has already locked, hence the
deadlock.
In my own application I coded around this by eventually not using the RuleAgent in-built
refresh mechanism, but instead periodically calling refreshRuleBase() on the RuleAgent in
the SAME thread used to create the Stateful session, thus avoiding any deadlock.
"Timer-15" daemon prio=6 tid=0x02f4b0e8 nid=0x1864 waiting for monitor entry
[0x038cf000..0x038cfa68]
at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:270)
- waiting to lock <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)
at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:656)
at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:570)
- locked <0x189a8d88> (a java.util.HashMap)
at org.drools.agent.PackageProvider.removePackage(PackageProvider.java:45)
at org.drools.agent.PackageProvider.applyChanges(PackageProvider.java:63)
at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:320)
at org.drools.agent.RuleAgent$2.run(RuleAgent.java:438)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
"DataSource(com.acme.Source)-2" daemon prio=4 tid=0x03027610 nid=0xfac waiting
for monitor entry [0x0378f000..0x0378fb68]
at org.drools.reteoo.ReteooRuleBase.newStatefulSession(ReteooRuleBase.java:225)
- waiting to lock <0x189a8d88> (a java.util.HashMap)
- locked <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)
at org.drools.common.AbstractRuleBase.newStatefulSession(AbstractRuleBase.java:284)
at com.acme.RunRules.flush(RunRules.java:3337)
at com.acme.ControlThread.run(ControlThread.java:465)
at java.lang.Thread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira