[rules-users] Trapping runaway rules

[rouvas at mm.di.uoa.gr]

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
>