Hide Forgot
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.
Link: Added: This issue depends JBRULES-2369
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
adding it to one offs so it gets flagged up
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.
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.
Link: Added: This issue is related to BRMS-248
Link: Added: This issue is related to BRMS-249
Help Desk Ticket Reference: Added: https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=373895&gid=1177
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.