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