[jboss-jira] [JBoss JIRA] Created: (JBRULES-2167) CLONE -Deadlock when RuleAgent thread refreshes rules while another thread creates a statefulSession
CLONE -Deadlock when RuleAgent thread refreshes rules while another thread creates a
statefulSession
----------------------------------------------------------------------------------------------------
Key: JBRULES-2167
URL: https://jira.jboss.org/jira/browse/JBRULES-2167
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: Neil Wallace
Assignee: Mark Proctor
Fix For: 5.0.1.FINAL
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