Re: [rules-users] Trapping runaway rules
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
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-boun...@lists.jboss.org [mailto:rules-users-
boun...@lists.jboss.org] On Behalf Of rou...@mm.di.uoa.gr
Sent: 30 August 2011 19:15
To: rules-users@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-boun...@lists.jboss.org
[mailto:rules-users-boun...@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
d...@basys.commailto:d...@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
Re: [rules-users] Trapping runaway rules
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-boun...@lists.jboss.org [mailto:rules-users-
boun...@lists.jboss.org] On Behalf Of rou...@mm.di.uoa.gr
Sent: 30 August 2011 19:15
To: rules-users@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-boun...@lists.jboss.org
[mailto:rules-users-boun...@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
d...@basys.commailto:d...@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
Re: [rules-users] Trapping runaway rules
On 30 August 2011 14:27, Dean Whisnant d...@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
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Trapping runaway rules
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-boun...@lists.jboss.org
[mailto:rules-users-boun...@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 d...@basys.commailto:d...@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.orgmailto:rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
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-boun...@lists.jboss.org
[mailto:rules-users-boun...@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
d...@basys.commailto:d...@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.orgmailto:rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
