Bug 724301 (BRMS-246)

Summary:	Subtle interaction between modify and no-loop causes dormant activations counter to get out of synch
Product:	[JBoss] JBoss Enterprise BRMS Platform 5	Reporter:	Edson Tirelli <ed.tirelli>
Component:	BRE (Expert, Fusion)	Assignee:	trev <tkirby>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	5.0.0 GA, 5.0.1
Target Milestone:	---
Target Release:	One Off Releases, 5.0.2
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/BRMS-246
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-03-30 12:41:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Edson Tirelli 2009-12-10 14:56:18 UTC

Date of First Response: 2009-12-10 10:02:01
Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=373895&gid=1177
securitylevel_name: Public

A rule with multiple non-constrained patterns having the no-loop attribute and a modify() call in the consequence would fire only once due to the dormant activations counter getting out of synch on the modify call.

Fixed in here:

http://fisheye.jboss.org/changelog/JBossRules?cs=30568



It seems the customer needs this delivered by January, but we need to double check.

Comment 1 Edson Tirelli 2009-12-10 14:56:47 UTC

Link: Added: This issue depends JBRULES-2369

Comment 2 trev 2009-12-10 15:02:01 UTC

the symptom was that the rule would not reactivate without the fix, when it obviously should
code has been committed to the 5.0.1 branch. 
Appropriate test is http://fisheye.jboss.org/viewrep/JBossRules/soa_branches/BRMS-5.0.1/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java?r1=28568&r2=30568
MiscTest 1.

If CP is not due in time, it may require a hot fix

Comment 3 trev 2009-12-10 15:03:05 UTC

adding it to one offs so it gets flagged up

Comment 4 Edson Tirelli 2009-12-10 19:14:39 UTC

Just to be clear, the conditions to trigger this problem are very strict:

* a rule with multiple patterns
* no constraints on the patterns (this is very rare)
* a modify in the consequence
* an update/modify call from another rule on one of the facts that match one of the patterns of this rule

So, I don't expect this will hit many users, other than the customer that raised the problem.

Comment 5 Tihomir Surdilovic 2009-12-14 16:24:53 UTC

Trevor, can you please let me know how are we going to handle this one-off? I would like to communicate it to the customer through the support ticket.

Thanks.

Comment 7 Len DiMaggio 2010-01-15 16:31:28 UTC

Link: Added: This issue is related to BRMS-248

Comment 8 Len DiMaggio 2010-01-15 16:31:28 UTC

Link: Added: This issue is related to BRMS-249

Comment 10 Darran Lofthouse 2010-02-09 13:28:45 UTC

Help Desk Ticket Reference: Added: https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=373895&gid=1177

Comment 12 Dana Mison 2010-04-01 04:54:29 UTC

Added to the BRMS 5.0.2 release notes as resolve:

JBRULES-2369
A rule with the following conditions would only fire once:

 - multiple patterns with no constraints,
 - a modify in the consequence,
 - and an update() or modify() call from another rule on one of the facts that matches one of the patterns of this rule.

This was because the dormant activations counter became unsynchronized when modify()  or update() was called. This has been fixed and the dormant activations counter now reports the correct value.