[jboss-jira] [JBoss JIRA] Created: (JBRULES-2167) CLONE -Deadlock when RuleAgent thread refreshes rules while another thread creates a statefulSession

[Neil Wallace (JIRA)]

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