Created attachment 533517 [details] Test case to reproduce bug Description of problem: Rule with enabled activation listener and working with activation facts is not fired first in the second iteration of StatefulKnowledgeSession. It is fired last and maybe that is the reason, that rule fired before is not canceled. Version-Release number of selected component (if applicable): BRMS 5.3.0 DEV4 How reproducible: Fire rule that cancels activation of another rule in the second iteration. Quite difficult to explain, so use attached test case. Steps to Reproduce: 1. Unzip and run attached test case. Actual results: In certain situations rule with activation listener set to 'direct' is not launched first. Maybe that is the cause why another specified rule is not canceled. Expected results: Rule with enabled direct activation listener should be fired first in all iterations of StatefulKnowledgeSession and should cancel rule that should be canceled.
Created attachment 534784 [details] Corrected test case
Test case updated, because the first one had error. You can ignore my first comment. Also bug reason is a bit different, but the bug summary is still correct - there is a problem with cancellation of a rule activation. Test case explanation: I use declarative agenda to cancel one rule in the first fireAllRules(). Everything works fine, specified rule is not fired. But in the second iteration, I just update both inserted facts and the result is different. Specified rule is not cancelled and the cancelling rule is still fired and cancels nothing. Run the second test case to see this behaviour, which is in my opinion incorrect.
Added pull request with test case: https://github.com/droolsjbpm/drools/pull/93
Mario Fusco <mario.fusco> updated the status of jira JBRULES-3442 to Resolved
Update status to ON_QA. Please verify them against ER6.
Verified in BRMS 5.3.0 ER6.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Using declarative agenda, activation canceling with kcontext.cancelActivation(Activation) did not always work as expected and some activations were still fired even after they have been canceled.
Hi Mario, For the release notes could you let me know how this issue was resolved. We need to let customers know about any changes in the code that could affect their systems. Thanks Lee
Hi Lee, The fix was quite straightforward. I had to add a canceled flag to the Activation (actually to the AgendaItem that implements the Activation interface). Then I set this flag to true when the activation is canceled and in the DefaultAgenda I test it in order to avoid to readd canceled activation. This is the commit that fixed the bug: https://github.com/droolsjbpm/drools/commit/c27b0ad343fc51bdfaf2e16b7f4818aa3928dabe Mario
Thank you Mario.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Using declarative agenda, activation canceling with kcontext.cancelActivation(Activation) did not always work as expected and some activations were still fired even after they have been canceled.+Using declarative agenda, activation canceling with kcontext.cancelActivation(Activation) did not always work as expected and some activations were still fired even after they had been canceled.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Using declarative agenda, activation canceling with kcontext.cancelActivation(Activation) did not always work as expected and some activations were still fired even after they had been canceled.+Using declarative agenda, activation canceling with kcontext.cancelActivation(Activation) did not always work as expected and some activations were still fired even after they had been canceled. This issue was resolved by adding a canceled flag to the Activation which is set to true when the activation is canceled. This flag is checked for to ensure canceled activations are not re-added.