969467 – A BatchCommand triggering a rule which modifies the KBase causes a deadlock

Bug 969467 - A BatchCommand triggering a rule which modifies the KBase causes a deadlock

Summary: A BatchCommand triggering a rule which modifies the KBase causes a deadlock

Keywords:
Status:	VERIFIED
Alias:	None
Product:	JBoss Enterprise BRMS Platform 5
Classification:	JBoss
Component:	BRE (Expert, Fusion)
Sub Component:
Version:	BRMS 5.3.1
Hardware:	Unspecified
OS:	Unspecified
Priority:	high
Severity:	high
Target Milestone:	---
Target Release:	---
Assignee:	Mario Fusco
QA Contact:
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	953308
TreeView+	depends on / blocked

Reported:	2013-05-31 13:28 UTC by Martin Weiler
Modified:	2024-01-01 01:36 UTC (History)
CC List:	0 users
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type:	Bug
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	JBRULES-3274	0	Major	Resolved	A BatchCommand triggering a rule which modifies the KBase causes a deadlock	2018-03-20 03:14:57 UTC

Description Martin Weiler 2013-05-31 13:28:03 UTC

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 13:47:16 UTC

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 16:05:42 UTC

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 11:08:22 UTC

Verified on 5.3.1.BRMS-P03.

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