>Not true...If I remove Rule 2 and change the attribute on Rule 1 to no-loop
>true, I still get infinite loop. The rule will process board 5, then board
>4, then back to board 5.
it is because stack is part of both tuples ([stack, board5], [stack, board4]).
if rule 1 fires it updates both tuples. The current one will be ignored but the other one won't which causes recursion.

This is my understanding. Maybe somebody else could confirm/deny.

Greg's solution would work just fine. The only issue I have with it is that the business requirements usually specify A, B and C. They don't specify 'not D'. It is there only to make our rules work, which is not ideal. Just my 2c.


On Wed, Jan 28, 2009 at 6:21 PM, Greg Barton <greg_barton@yahoo.com> wrote:
--- On Wed, 1/28/09, Dan Seaver <dan.seaver@ge.com> wrote:

> Yes, I understand why Rule 2 doesn't fire when the attribute is set to
> lock-on-active, but why does no-loop work with Rule 2, but not with Rule
> 1?

Just to jump in here, let me say this: I have no idea. :)

Now a suggestion...

This is one reason I like to primarily rely on the rule conditions to control activation.  i.e. rules look like this:

when
 A, B, and C
 but not D [D is performed in rule action]
then
 do D
end

It's self documenting, though does require more maintenance, as you may have to change the rule condition whenever you change the rule action.

The tools drools provides for activation control are general purpose, and as such are necessarily the sledgehammer approach. :)  Nothing wrong with that per se, I just prefer the a more fine grained approach, and the extra control that provides.




_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users