[rules-users] Trapping runaway rules

Wed Aug 31 04:55:48 EDT 2011

> Swindells, Thomas wrote:
> > I've found no-loop to be pretty much completely useless.
> > It only stops the rule from triggering itself, but it doesn't stop
> > loops where multiple rules
> 
> Correct. I suggested "no-loop" exactly from preventing the same rule to fire
> in a loop.
[Swindells, Thomas] My point is that generally isn't particularly helpful as it is 
exceedingly brittle, doesn't do what the name suggests and is useless as soon 
as any other rules modify the same object.
> 
> Another road to follow, could be to using agenda groups for user generated
> rules.
> 
> -Stathis
> 
> > constantly trigger each other. Eg when they both depend on and modify
> > the same fact.
> > Individually with no-loop they would both work fine, but combined
> > together you get into a loop.
> >
> > Thomas
> >
> >
> >> -----Original Message-----
> >> From: rules-users-bounces at lists.jboss.org [mailto:rules-users-
> >> bounces at lists.jboss.org] On Behalf Of rouvas at mm.di.uoa.gr
> >> Sent: 30 August 2011 19:15
> >> To: rules-users at lists.jboss.org
> >> Subject: Re: [rules-users] Trapping runaway rules
> >>
> >> I would also suggest that you add a "no-loop" directive to each one
> >> of your rules, at least to the ones "written" by the end-users (if I
> >> understood correctly).
> >>
> >> As I have (painfully) found, it is extremely easy to produce
> >> never-ending loops on (end)user-created rules.
> >>
> >> -Stathis
> >>
> >> Dean Whisnant wrote:
> >> > Wolfgang,
> >> >
> >> > Thanks for the thoughts and suggestions.  My current implementation
> >> > does have a limited number of rules we would expect to fire, with
> >> > little chance of multiple firings.  I understand the beauty of the
> >> > way the engine re-evaluates and re-fires if needed (oversimplification).
> >> >
> >> > After posing the question here I dug into the javadocs and saw that
> >> > fireallrules accepts and int for the max activations and returns an
> >> > int of the number of activations.  I feel pretty comfortable using
> >> > this method and comparing the in and out ints to be able to do some
> >> > exception handling (email notifications of issues).
> >> >
> >> > If anyone else has other possible solutions/formulas they would use
> >> > to determine a rule is running away I'd be interested in hearing
> >> > your
> >> ideas.
> >> >
> >> > I agree, the person with a bit of savvy would detect the errors
> >> > themselves, but the nature of my application is that the firing is
> >> > cloud based and somewhat invisible to the rule creators.  What I
> >> > hope to be able to do with halting the process and informing them
> >> > of runaways is that they can then review their log of rules fired
> >> > for each transaction and either resolve the rule issue themselves
> >> > or
> >> contact
> >> others who can assist them.
> >> > The one we had last week had created a 6 Gb rules fired log before
> >> > anyone was suspicious that there was an issue. :O
> >> >
> >> > Again, thank you for the wonderful feedback!
> >> >
> >> > Dean
> >> >
> >> > From: rules-users-bounces at lists.jboss.org
> >> > [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Wolfgang
> >> > Laun
> >> > Sent: Tuesday, August 30, 2011 11:20 AM
> >> > To: Rules Users List
> >> > Subject: Re: [rules-users] Trapping runaway rules
> >> >
> >> > On 30 August 2011 14:27, Dean Whisnant
> >> > <dean at basys.com<mailto:dean at basys.com>> wrote:
> >> > My project involves rule creation by customers, business analysts,
> >> > and developers.  We have a base set of rules that fire for every
> >> > transaction and then we fire custom rules within a stateful session.
> >> > An issue I've started to run into is rules being created that fire
> >> > endlessly.  I initialize the session with an event listener that we
> >> > use to extract all rules fired for each line item of a transaction.
> >> > Once the session is initialized and all rules from various agenda
> >> > groups loaded we do a fireall rules.
> >> >
> >> > My questions are:
> >> > 1) how can I detect I have a runaway rule/rules.
> >> >        Is there a method or listener that could detect this for me?
> >> > Does anyone have a formula they use to do so?  I had thought that I
> >> > could use my event listener that I track the rules with to grab the
> >> > last X number of rules fires and see if rule y gets fired more that
> >> > z times.  But is there a simpler method?
> >> >
> >> > It's not even as simple as that. ;-) Multiple firing of a rule r
> >> > within n firings may not be loops if this happens with different
> >> > facts bound to patterns.
> >> >
> >> >
> >> > 2) once I've detected a runaway rule, how can I gracefully stop
> >> > drools rule execution? I read of the command drools.halt in
> >> > different posts, but not sure if this would be what I'm looking at doing.
> >> >
> >> > If you detect it during a consequence execution, throw an exception
> >> > and catch it with a custom consequence exception handler.
> >> >
> >> > Using a limit on fire all rules might be another way, in
> >> > combination with logging all activations.
> >> >
> >> > Finally, someone with a little savvy should be able to detect some
> >> > just by looking at them. The telltale marks are well known...
> >> >
> >> > -W
> >> >
> >> >
> >> > Any thoughts are appreciated.
> >> >
> >> > Thank you!
> >> >
> >> > Dean
> >> >                StatefulKnowledgeSession ksession =
> >> > buildOutgoingStatefulKnowledgeSession(supportingUDTList);
> >> >                // AgendaEventListener agendaListener = new
> >> > HipaaAgendaListener();
> >> >                ksession.addEventListener(_ruleLog);
> >> >
> >> >                for (int i = 0; i < _agendaGroups.size(); i++)
> >> >                {
> >> >                        if (_log.isDebugEnabled()) _log.debug("Focus
> >> > on Agenda Group " + _agendaGroups.get(i));
> >> >
> >>
> ksession.getAgenda().getAgendaGroup(_agendaGroups.get(i)).setFocus();
> >> >                        // Fire them all
> >> >                        try
> >> >                        {
> >> >                                ksession.fireAllRules();
> >> >                        }
> >> >                        catch (Exception e)
> >> >                        {
> >> >                                _log.error("FireAllRules exception.
> >> Error="
> >> > + e.getMessage()); // error
> >> >                        }
> >> >                }
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > rules-users mailing list
> >> > rules-users at lists.jboss.org<mailto:rules-users at lists.jboss.org>
> >> > https://lists.jboss.org/mailman/listinfo/rules-users
> >> >
> >> > _______________________________________________
> >> > rules-users mailing list
> >> > rules-users at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/rules-users
> >> >
> >>
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> >
> **********************************************************
> ************
> > **************** This message is confidential and intended only for
> > the addressee. If you have received this message in error, please
> > immediately notify the postmaster at nds.com and delete it from your
> > system as well as any copies.
> > The content of e-mails as well as traffic data may be monitored by NDS
> > for employment and security purposes. To protect the environment
> > please do not print this e-mail unless necessary.
> >
> > NDS Limited. Registered Office: One London Road, Staines, Middlesex,
> > TW18 4EX, United Kingdom. A company registered in England and Wales.
> > Registered no. 3080780. VAT no. GB 603 8808 40-00
> >
> **********************************************************
> ************
> > ****************
> >
>