Bug 969467 - A BatchCommand triggering a rule which modifies the KBase causes a deadlock
A BatchCommand triggering a rule which modifies the KBase causes a deadlock
Status: VERIFIED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion) (Show other bugs)
BRMS 5.3.1
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Mario Fusco
Marek Winkler
:
Depends On:
Blocks: 953308
  Show dependency treegraph
 
Reported: 2013-05-31 09:28 EDT by Martin Weiler
Modified: 2013-06-14 07:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBRULES-3274 Major Resolved A BatchCommand triggering a rule which modifies the KBase causes a deadlock 2015-10-07 02:23 EDT

  None (edit)
Description Martin Weiler 2013-05-31 09:28:03 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.
Comment 1 Edson Tirelli 2013-05-31 09:47:16 EDT
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)
Comment 2 Mario Fusco 2013-05-31 12:05:42 EDT
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.
Comment 3 Marek Winkler 2013-06-14 07:08:22 EDT
Verified on 5.3.1.BRMS-P03.

Note You need to log in before you can comment on or make changes to this bug.