11:48 a.m.
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(a)lists.jboss.org [mailto:rules-users-bounces@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@basys.com<mailto:dean@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@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users