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: [email protected] [mailto:rules-users- >> [email protected]] On Behalf Of [email protected] >> Sent: 30 August 2011 19:15 >> To: [email protected] >> 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: [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 > > > ************************************************************************************** > This message is confidential and intended only for the addressee. If you > have received this message in error, please immediately notify the > [email protected] 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 > ************************************************************************************** > _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
