Red Hat Bugzilla – Bug 969467
A BatchCommand triggering a rule which modifies the KBase causes a deadlock
Last modified: 2013-06-14 07:08:22 EDT
Description of problem: Platform issue for JBRULES-3274: Create a BatchCommand containing an insert and a fireAll. Make that inserted fact activate a rule which modifies the KBase, e.g. adding another rule on the fly. When executing the batch command, the thread will acquire a read lock. The kBase modification will then require a write lock, causing the deadlock.
Mario, here is the exception the customer is receiving. As we discussed, see if you can create the test case to reproduce the problem following that strategy I mentioned. If it is not possible, then just backport the fix. caused by java.lang.ArrayIndexOutOfBoundsException: 16java.lang.ArrayIndexOutOfBoundsException: 16 at org.drools.core.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:316) at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:422) at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:370) at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:272) at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:99) at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71) at org.drools.reteoo.Rete.assertObject(Rete.java:105) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:285) at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:435) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:976) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:322) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:887) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:846) at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:267) at be.ing.tar.jboss.brms.engine.pr.JBossBRMSPREngineManager.executeContext(JBossBRMSPREngineManager.java:172) at be.ing.tar.jboss.brms.engine.pr.JBossBRMSPREngineManager.executePricingRulesInRulesEngine(JBossBRMSPREngineManager.java:284) at be.ing.tar.jboss.brms.engine.pr.JBossBRMSPREngineManager.executePricingRules(JBossBRMSPREngineManager.java:111) at be.ing.tar.jrules.engine.pr.OperationalJRulesEngineManager.executePricingRules(OperationalJRulesEngineManager.java:65) at be.ing.tar.pm.prm.OperationalCatalogRuleManager.givePricingElementForCatalog(OperationalCatalogRuleManager.java:662) at be.ing.tar.am.arm.OperationalAgreementRuleManager.seeInCatalogRules(OperationalAgreementRuleManager.java:977) at be.ing.tar.am.arm.OperationalAgreementRuleManager.givePricingElementForAgreementAndCyclicOperation(OperationalAgreementRuleManager.java:499) at be.ing.tar.cm.cyclic.OperationalCyclicChargeManager.getSettlementPeriodicityAttributeForCyclicOperation(OperationalCyclicChargeManager.java:1502) at be.ing.tar.cm.cyclic.OperationalCyclicChargeManager.getAllCyclicOperationsForAgreement(OperationalCyclicChargeManager.java:1066) at be.ing.tar.cm.cyclic.OperationalCyclicChargeManager.getAllCyclicOperationsForAgreement(OperationalCyclicChargeManager.java:960) at be.ing.tar.cm.cyclic.OperationalCyclicChargeManager.processCyclicOperationsForCyclicBatchAndCreditCardAgreement(OperationalCyclicChargeManager.java:253) at be.ing.tar.om.batch.opercyclcredcard.OperCyclCCBatchManager.processOneWorkDetailImplementation(OperCyclCCBatchManager.java:265) at be.ing.tar.om.batch.BatchBlockOfWorkBreakable.processOneWorkDetail(BatchBlockOfWorkBreakable.java:66) at be.ing.tar.om.batch.BatchBlockProcessor.processOneCommandLine(BatchBlockProcessor.java:329) at be.ing.tar.om.batch.BatchBlockProcessor.run(BatchBlockProcessor.java:100) at be.ing.tar.om.batch.threads.BatchThreadWorker.run(BatchThreadWorker.java:69)
I backported to 5.3.x the Fix for JBRULES-3274 that I developed in the 5.4.x. Also I tried to reproduce the problem with this test https://github.com/droolsjbpm/drools/blob/5.3.x/drools-compiler/src/test/java/org/drools/integrationtests/MultithreadTest.java#L86 but I couldn't. I think that this test case is somewhat meaningful anyway so I decided to the codebase.
Verified on 5.3.1.BRMS-P03.