Bug 862325

Summary:	Fact modification improperly cancels activations
Product:	[JBoss] JBoss Enterprise BRMS Platform 5	Reporter:	Edson Tirelli <etirelli>
Component:	BRE (Expert, Fusion)	Assignee:	Nobody <nobody>
Status:	VERIFIED ---	QA Contact:
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	BRMS 5.3.0.GA	CC:	kverlaen
Target Milestone:	ER4
Target Release:	BRMS 5.3.1 GA
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	An optimization engine bug occurred when the first rule to fire in a session modified a fact that had activations pending. Accordingly, rules that depended on the modified fact were no longer firing. This has been resolved by removing the particular optimization for the engine that is no longer relevant to the new algorithms, and the rules now properly fire.	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:	---	Target Upstream Version:
Embargoed:

Description Edson Tirelli 2012-10-02 16:04:15 UTC

Description of problem:
If the first rule to fire in a session modifies a fact, the engine improperly cancels pending activations depending on that fact.

Version-Release number of selected component (if applicable):
5.3.0

How reproducible:
A test case where the first rule to fire modifies a fact that previously activated other rules.

Actual results:
Activations improperly cancelled

Expected results:
Activations are not cancelled and fire properly.

Additional info:
This was raised by a partner. The actual details/rules are confidential and shared under NDA. I am opening this ticket for the partner.

Comment 1 Edson Tirelli 2012-10-02 16:05:41 UTC

This bug occurs only in a very specific scenario, but it is very critical as it silently fails causing the engine to produce wrong results.

Comment 2 Edson Tirelli 2012-10-16 00:19:41 UTC

Fix backported to 5.3.x.

Comment 3 Edson Tirelli 2012-10-31 15:55:58 UTC

The test case to reproduce and verify this problem is committed here:

https://github.com/droolsjbpm/drools/commit/e80ed64d621ec5d4671147cc400e857e652578a7

Please note that the scenario is very specific, so even changing the order of the updates on the consequence will prevent the bug from showing up.

Comment 4 Douglas Hoffman 2012-11-06 00:58:40 UTC

I have updated the Doc Text for documentation Release Notes.
Thank you for the information.

- Doug

Comment 5 Marek Winkler 2012-11-12 11:26:42 UTC

Verified on 5.3.1.BRMS-ER4.