We have encountered a problem with a lock getting generated on an AbstractRuleBase and then never released causing new threads to not be able to execute in that RuleBase. We are on an older version 5.0.1 of Drools and are working on creating a unit test that we can use to see if the defect exists in newer releases. That said, any tips that somebody might have to reproduce a concurrency issue related to rule bases used across threads would be very helpful. Or if there are other similar JIRA entries that we can look at that?
This occurs only when the system is under relatively high load and there potentially could be 100 threads attempting to access and use the same rulebase.
This is very similar to this JIRA:
We have confirmed that we have the fix generated in that ticket.
The general related stack traces for the waiting threads is :
java.lang.Thread.State: WAITING
…
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:423)
at org.drools.common.AbstractRuleBase.readLock(AbstractRuleBase.java:414)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:866)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:788)
…
java.lang.Thread.State: BLOCKED on org.drools.reteoo.ReteooStatefulSession@fec3cf owned by: DefaultMessageListenerContainer-145
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:627)
at org.drools.base.FireAllRulesRuleBaseUpdateListener.beforeRuleBaseUnlocked(FireAllRulesRuleBaseUpdateListener.java:41)
at org.drools.event.RuleBaseEventSupport.fireBeforeRuleBaseUnlocked(RuleBaseEventSupport.java:123)
at org.drools.common.AbstractRuleBase.unlock(AbstractRuleBase.java:408)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:517)
at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:388)
…..