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: [email protected] > [mailto:[email protected]] 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 > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[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
