[rules-users] Trapping runaway rules

rouvas at mm.di.uoa.gr rouvas at mm.di.uoa.gr
Wed Aug 31 04:31:41 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.

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
> **************************************************************************************
>

More information about the rules-users mailing list