Interesting. It would probably help if the docs made that clear. :) I’m off to get myself some sleep just now, but I’ll do a push of the repo to GitHub tomorrow and point you at the tests.
A summary of the behaviour is that I was seeing multiple activations of a rule, which went away when I added “lock-on-active” to that rule. However, that didn’t prevent other rules from activating afterwards. Unfortunately in a separate test, which added some more rules which would activate first, that rule ceased to activate at all. Despite the fact that it was the only rule with “lock-on-active” and no rules had an "agenda-group" attribute. This is using 5.5. I’ll probably be upgrading to the 5.6 CR tomorrow or at the weekend, so I should be able to confirm what happens there. I came across it because I was experimenting with mechanisms to ensure that a rule only activates once. It’s something that I find quite useful in a stateless session. Steve On 7 Nov 2013, at 22:29, Davide Sottara <[email protected]> wrote: > Lock-on-active was very recently the subject of a bad bug, DROOLS-281, > which has been fixed a few days ago. > This said, all rules that do not have an explicit group set end up in > the "MAIN" (or "DEFAULT", I don't remember) > agenda group and then behave accordingly. > Could you post the Drools version number and some more details on the > example and the "unexpected" behavior? > Thanks > Davide > > > On 11/07/2013 03:01 PM, Stephen Masters wrote: >> Hi folks, >> >> According to the user guide, lock-on-active “inhibits additional activations >> of all rules with this flag set within the same rule flow or agenda group”. >> >> I was doing a little testing of some rules earlier today, and noticed that >> lock-on-active seems to change behaviour when applied to rules which don’t >> have an agenda-group or rules flow-group defined. It also seemed to have a >> slightly inconsistent effect, although that may just be me not realising >> what it’s supposed to do. >> >> There doesn’t appear to be any documentation of what the attribute means >> when a rule is not part of a rule flow or agenda group. So I was wondering >> whether perhaps there is an expected/official behaviour, which is just not >> documented. Or is lock-on-active without a rule flow or agenda group an >> error? In which case is there a reason why it doesn’t cause a compilation >> error when the knowledge base is built? >> >> Yours curiously... >> >> Steve >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
