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

[Shahad Ahmed (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBRULES-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shahad Ahmed updated JBRULES-1876:
----------------------------------

    Attachment: deadlock.zip


I've been able to reproduce the deadlock with 5.0.0-M4. 

I've attached the file deadlock.zip that contains a modified version of the drools "Hello World" example. This loads rules via a RuleAgent and then repeatedly fires the rules for a minute, with the rule refresh polling set to 5 seconds. I can reproduce the deadlock once in every 4 or 5 test runs, where a test run is as follows:

1. Run the DroolsAgentTest application.

2. Once you start seeing the "Hello World" messages on the console, modify the SampleAgent.drl file by commenting out the println in the "Hello World" Rule and save the file, i.e. modify as follows: //System.out.println( message ). This changes the rules file so that the polling will refresh the rules.

3. The output should stop printing "Hello World" and only show "Goodbye cruel world". However, occasionally a deadlock happens and the output does not change and the just hangs.

4. Note that if you do not get a deadlock once you save the modified rules file then remove the modification (i.e. remove the //) and save and see if it deadlocks. I sometimes have to modify and change the rules file a few times during the 1 minute run to get the deadlock. Note that the length of the run can be increase from a minute by changing the TEST_PERIOD value in the test class, in case you need more time to modify the rules file during a run.



> 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
>         Attachments: deadlock.zip
>
>
> 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