11:06 a.m.
Hello,
I've 2 rules which should be similar but the result is different and I can't
understand why :
I insert an object Message() into drools with the following rule :
rule "rule_a"
timer (int:1s 1s)
when
SimpleClock ( d : dateInMillisec != 0 ) // SimpleClock give the current
time (set by a java timer and an update)
m : Message ( internalEndDate < d )
then
System.out.println( "rule a");
m.setInternalEndDate (d + 10000);
* retract (m);*
* insert (m);*
end
the result is fine : a message every 10.
If I replace the rule_a by the rule_b : (because an update should be better
than an retract/insert I guess)
rule "rule_b"
timer (int:1s 1s)
when
SimpleClock ( d : dateInMillisec != 0 ) // Simple slock give the current
time (set by a java timer and an update)
m : Message ( internalEndDate < d )
then
System.out.println( "rule b");
m.setInternalEndDate (d + 10000);
* update (m);*
end
the result is bad : a message every 1 second.
It act as if the attibute message.internalEndDate wasn't updated in the
drools engine. Could someone explain me if/why this behaviour is normal ?
Thanks in advance
Marc
12:23 p.m.
Hi Marc,
Your rules do not immediately reveal anything remarkable to me, so I do not
have an explanation or solution just yet.
Here is what I would do to narrow down on the problem:
Add an output in your rules that print the internal end date and the current
date in each RHS of the rules.
It is unlikely that the WM is not updated at all, that would cause
internalEndDate to remain unchanged and rules wouldn't be fired anymore.
Regards,
Frank
Marc Strabin wrote:
Hello,
I've 2 rules which should be similar but the result is different and I
can't
understand why :
I insert an object Message() into drools with the following rule :
rule "rule_a"
timer (int:1s 1s)
when
SimpleClock ( d : dateInMillisec != 0 ) // SimpleClock give the current
time (set by a java timer and an update)
m : Message ( internalEndDate < d )
then
System.out.println( "rule a");
m.setInternalEndDate (d + 10000);
* retract (m);*
* insert (m);*
end
> the result is fine : a message every 10.
If I replace the rule_a by the rule_b : (because an update should be
better
than an retract/insert I guess)
rule "rule_b"
timer (int:1s 1s)
when
SimpleClock ( d : dateInMillisec != 0 ) // Simple slock give the current
time (set by a java timer and an update)
m : Message ( internalEndDate < d )
then
System.out.println( "rule b");
m.setInternalEndDate (d + 10000);
* update (m);*
end
> the result is bad : a message every 1 second.
It act as if the attibute message.internalEndDate wasn't updated in the
drools engine. Could someone explain me if/why this behaviour is normal ?
Thanks in advance
Marc
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
12:29 p.m.
I'm sorry, that didn't make any sense. An un-updated internal enddate would
indeed cause the LHS condition to remain true, and the timer will cause it
to fire each second.
My bad...
FrankVhh wrote:
Hi Marc,
Your rules do not immediately reveal anything remarkable to me, so I do
not have an explanation or solution just yet.
Here is what I would do to narrow down on the problem:
Add an output in your rules that print the internal end date and the
current date in each RHS of the rules.
It is unlikely that the WM is not updated at all, that would cause
internalEndDate to remain unchanged and rules wouldn't be fired anymore.
Regards,
Frank
Marc Strabin wrote:
>
> Hello,
> I've 2 rules which should be similar but the result is different and I
> can't
> understand why :
>
> I insert an object Message() into drools with the following rule :
>
> rule "rule_a"
> timer (int:1s 1s)
> when
> SimpleClock ( d : dateInMillisec != 0 ) // SimpleClock give the current
> time (set by a java timer and an update)
> m : Message ( internalEndDate < d )
> then
> System.out.println( "rule a");
> m.setInternalEndDate (d + 10000);
> * retract (m);*
> * insert (m);*
> end
>
>
> > the result is fine : a message every 10.
>
> If I replace the rule_a by the rule_b : (because an update should be
> better
> than an retract/insert I guess)
>
> rule "rule_b"
> timer (int:1s 1s)
> when
> SimpleClock ( d : dateInMillisec != 0 ) // Simple slock give the current
> time (set by a java timer and an update)
> m : Message ( internalEndDate < d )
> then
> System.out.println( "rule b");
> m.setInternalEndDate (d + 10000);
> * update (m);*
> end
>
>
> > the result is bad : a message every 1 second.
>
> It act as if the attibute message.internalEndDate wasn't updated in the
> drools engine. Could someone explain me if/why this behaviour is normal ?
> Thanks in advance
>
> Marc
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
1:20 p.m.
I think there is an open JIRA for a very similar issue:
JBRULES-2825 "rule with timer and CE not keeps firing after turning false"
I have added these two rules as a comment.
However, the timer isn't necessary in this here case. Since the SimpleClock
fact is updated periodically, the engine will fire the rule as soon as
dateInMillisec exceeds the clock value in the Message fact.
Both rules work correctly, if written without the timer.
Actuallay, the timer doesn't have any effect (except wasting a few cycles).
If the LHS becomes true, it delays the first firing by 1s, and then the LHS
is made false by changing the Message object. This stops the timer! But
then, eventually, the LHS becomes true again, and *another timer *is
started, delays 1s, fires, and terminates.
-W
2011/3/29 Marc Strabin <marc.strabin(a)gmail.com>:
Hello,
I've 2 rules which should be similar but the result is different and I
can't
understand why :
I insert an object Message() into drools with the following rule :
rule "rule_a"
timer (int:1s 1s)
when
SimpleClock ( d : dateInMillisec != 0 ) // SimpleClock give the current
time (set by a java timer and an update)
m : Message ( internalEndDate < d )
then
System.out.println( "rule a");
m.setInternalEndDate (d + 10000);
retract (m);
insert (m);
end
> the result is fine : a message every 10.
If I replace the rule_a by the rule_b : (because an update should be
better
than an retract/insert I guess)
rule "rule_b"
timer (int:1s 1s)
when
SimpleClock ( d : dateInMillisec != 0 ) // Simple slock give the current
time (set by a java timer and an update)
m : Message ( internalEndDate < d )
then
System.out.println( "rule b");
m.setInternalEndDate (d + 10000);
update (m);
end
> the result is bad : a message every 1 second.
It act as if the attibute message.internalEndDate wasn't updated in the
drools engine. Could someone explain me if/why this behaviour is normal ?
Thanks in advance
Marc
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:04 p.m.
Thanks,
The JBRULES-2825 seems to be a similar issue indeed !
The timer is necessary: When change the value of SimpleClock and I only do
an update (obj), without calling fireAllRules(). That way the rule doesn't
fire... Is-it an other problem ??
If I do a update + fireAllRulles() when I change the timer, the rule_b fire
fine every 10 seconds. (without timer in the rule..)
I think there is an open JIRA for a very similar issue:
JBRULES-2825 "rule with timer and CE not keeps firing after turning
false"
I have added these two rules as a comment.
However, the timer isn't necessary in this here case. Since the SimpleClock
fact is updated periodically, the engine will fire the rule as soon as
dateInMillisec exceeds the clock value in the Message fact.
Both rules work correctly, if written without the timer.
Actuallay, the timer doesn't have any effect (except wasting a few cycles).
If the LHS becomes true, it delays the first firing by 1s, and then the LHS
is made false by changing the Message object. This stops the timer! But
then, eventually, the LHS becomes true again, and *another timer *is
started, delays 1s, fires, and terminates.
-W
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
9:34 p.m.
On 29 March 2011 19:04, marc <marc.strabin(a)gmail.com> wrote:
Thanks,
The JBRULES-2825 seems to be a similar issue indeed !
The timer is necessary: When change the value of SimpleClock and I only do
an update (obj), without calling fireAllRules(). That way the rule doesn't
fire... Is-it an other problem ??
If I do a update + fireAllRulles() when I change the timer, the rule_b fire
fine every 10 seconds. (without timer in the rule..)
Sorry, but I do not understand what you mean by any of these two scenarios.
-W
I think there is an open JIRA for a very similar issue:
JBRULES-2825 "rule with timer and CE not keeps firing after turning
false"
I have added these two rules as a comment.
However, the timer isn't necessary in this here case. Since the SimpleClock
fact is updated periodically, the engine will fire the rule as soon as
dateInMillisec exceeds the clock value in the Message fact.
Both rules work correctly, if written without the timer.
Actuallay, the timer doesn't have any effect (except wasting a few cycles).
If the LHS becomes true, it delays the first firing by 1s, and then the LHS
is made false by changing the Message object. This stops the timer! But
then, eventually, the LHS becomes true again, and *another timer *is
started, delays 1s, fires, and terminates.
-W
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:49 a.m.
There might be some conceptual problem going on here.
Calling a ruleset with just (one of- those rules would indeed not produce
the desired results (leaving the timer aside).
Here is what happens:
1) The rule matches because endtime < currenttime
2) Rule is put on agenda
3) As the only rule in the agenda, it is executed and sets the endtime to a
couple of seconds in the future
4) WM is updated and rules are re-evaluated
5) No more matching rules because endtime > currenttime
6) Rule execution stops
I do not know exactly what Marc is doing, but I assume he is trying to keep
the engine alive by calling fireAllrules time after time. Part of the
problem may be lying here. Could you show us the all parts of your code
where you have "fireAllRules() " coded?
Additionally, we can be hoping, but the issue with the timer will probably
remain. Did you try to System.out the values of endtime and currenttime
after each rule execution?
Regards,
Frank
Wolfgang Laun-2 wrote:
On 29 March 2011 19:04, marc &lt;marc.strabin(a)gmail.com&gt; wrote:
> Thanks,
> The JBRULES-2825 seems to be a similar issue indeed !
>
> The timer is necessary: When change the value of SimpleClock and I
only do
> an update (obj), without calling fireAllRules(). That way the rule
doesn't
> fire... Is-it an other problem ??
>
> If I do a update + fireAllRulles() when I change the timer, the
rule_b fire
> fine every 10 seconds. (without timer in the rule..)
>
> Sorry, but I do not understand what you mean by any of these two
scenarios.
-W
>
> I think there is an open JIRA for a very similar issue:
>
> JBRULES-2825 &quot;rule with timer and CE not keeps firing after
turning
> false&quot;
>
> I have added these two rules as a comment.
>
> However, the timer isn't necessary in this here case. Since the
SimpleClock
> fact is updated periodically, the engine will fire the rule as soon
as
> dateInMillisec exceeds the clock value in the Message fact.
>
> Both rules work correctly, if written without the timer.
>
> Actuallay, the timer doesn't have any effect (except wasting a few
cycles).
> If the LHS becomes true, it delays the first firing by 1s, and then
the LHS
> is made false by changing the Message object. This stops the timer!
But
> then, eventually, the LHS becomes true again, and *another timer *is
> started, delays 1s, fires, and terminates.
>
> -W
>
>
>
> --
> View this message in context:
>
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
11:17 a.m.
Indeed - I should have mentioned this previously. Using timers
apparently keeps the session alive even though there's a return from
fireAllRules(). This, by itself, may be considered a bug.
But whenever rule-based processing is using real (or pseudo-real)
time, I feel that fireUntilHalt() should be used primarily - and
that's what I was using to confirme the working of both rules without
timer().
But calling fireAllRules() after updating the SimpleClock() works equally well.
Anyway: Using timer() is *not* correct in this situation.
-W
On 30 March 2011 10:49, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
There might be some conceptual problem going on here.
Calling a ruleset with just (one of- those rules would indeed not produce
the desired results (leaving the timer aside).
Here is what happens:
1) The rule matches because endtime < currenttime
2) Rule is put on agenda
3) As the only rule in the agenda, it is executed and sets the endtime to a
couple of seconds in the future
4) WM is updated and rules are re-evaluated
5) No more matching rules because endtime > currenttime
6) Rule execution stops
I do not know exactly what Marc is doing, but I assume he is trying to keep
the engine alive by calling fireAllrules time after time. Part of the
problem may be lying here. Could you show us the all parts of your code
where you have "fireAllRules() " coded?
Additionally, we can be hoping, but the issue with the timer will probably
remain. Did you try to System.out the values of endtime and currenttime
after each rule execution?
Regards,
Frank
Wolfgang Laun-2 wrote:
>
> On 29 March 2011 19:04, marc &lt;marc.strabin(a)gmail.com&gt; wrote:
>
> > Thanks,
> > The JBRULES-2825 seems to be a similar issue indeed !
> >
> > The timer is necessary: When change the value of SimpleClock and I
> only do
> > an update (obj), without calling fireAllRules(). That way the rule
> doesn't
> > fire... Is-it an other problem ??
> >
> > If I do a update + fireAllRulles() when I change the timer, the
> rule_b fire
> > fine every 10 seconds. (without timer in the rule..)
> >
> > Sorry, but I do not understand what you mean by any of these two
> scenarios.
> -W
>
>
>
> >
> > I think there is an open JIRA for a very similar issue:
> >
> > JBRULES-2825 &quot;rule with timer and CE not keeps firing after
> turning
> > false&quot;
> >
> > I have added these two rules as a comment.
> >
> > However, the timer isn't necessary in this here case. Since the
> SimpleClock
> > fact is updated periodically, the engine will fire the rule as soon
> as
> > dateInMillisec exceeds the clock value in the Message fact.
> >
> > Both rules work correctly, if written without the timer.
> >
> > Actuallay, the timer doesn't have any effect (except wasting a few
> cycles).
> > If the LHS becomes true, it delays the first firing by 1s, and then
> the LHS
> > is made false by changing the Message object. This stops the timer!
> But
> > then, eventually, the LHS becomes true again, and *another timer *is
> > started, delays 1s, fires, and terminates.
> >
> > -W
> >
> >
> >
> > --
> > View this message in context:
> >
>
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
> > Sent from the Drools - User mailing list archive at Nabble.com.
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:47 p.m.
I was using only one fireAllRules() after insert(message) and not
fireUntilHalt(). But is should be enough : as the rule change & update the
fact, the rule is applied again (10 seconds later, and not 1second).
With fireUntilHalt() the rule work fine (and without timer)... but it burns
the CPU (the java process reach 50% on a bi-proc) while a simple call to
fireAllRues() after the timer update use nothing... This doesn't make sense
to me because the drools engine is only notified of a fact modification only
1 time per second (the timer update), so it should only fire all rules a
this moment and that all (just like a fireAllRules() after the
update(SimpleClock) does), so why does it takes so much CPU ? I can post the
code but I should open a other thread because it not the same "problem" ?
About adding log to trace the values of endDate, the traces show correct
values. But it doesn't trace the value viewed by the drools engine itself
wich could be different (just as if I don't do an update() after a
modification)
Marc
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
1:06 p.m.
On 30 March 2011 12:47, marc <marc.strabin(a)gmail.com> wrote:
I was using only one fireAllRules() after insert(message) and not
fireUntilHalt(). But is should be enough : as the rule change & update the
fact, the rule is applied again (10 seconds later, and not 1second).
If there are no timers, fireAllRules() terminates as soon as all pending
activations have been fired. Changing a fact later on will create activations,
but not fire rules.
With fireUntilHalt() the rule work fine (and without timer)... but it burns
the CPU (the java process reach 50% on a bi-proc) while a simple call to
fireAllRues() after the timer update use nothing... This doesn't make sense
to me because the drools engine is only notified of a fact modification only
1 time per second (the timer update), so it should only fire all rules a
this moment and that all (just like a fireAllRules() after the
update(SimpleClock) does), so why does it takes so much CPU ? I can post the
code but I should open a other thread because it not the same "problem" ?
Another known problem, I think. I don't see anything like that while
using a (my)
build from a developer baaseline about 6 weeks ago.
About adding log to trace the values of endDate, the traces show correct
values. But it doesn't trace the value viewed by the drools engine itself
wich could be different (just as if I don't do an update() after a
modification)
Sorry, but your way of expressing yourself beats me again.
-W
Marc
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:08 p.m.
Not entirely,
Wolfgang could probably explain this a lot better than me, but I will give
it a try.
1) Rule execution stops -or it should stop- as soon as there are no more
rules with conditions that are true. Therefor, the rules should only be
executed once.
2) You would not need your timer because the only thing it does, is to slow
down rule execution 1 sec. And, as wolfgang pointed out, the timer stops, or
should stop, once the condition becomes false.
Now, in your case, it appears the only job the timer does, is to keep the
session alive, which appears to be a bug.
What you need, is not a timer. You need something to keep your session alive
during the time your conditions are false. Preferably something that is not
buggy. This could be achieved by f.e. fireUntilHalt(), or whatever
intelligent design you can come up with.
About adding log to trace the values of endDate, the traces show
correct
values. But it doesn't trace the value viewed by the drools engine itself
wich could be different (just as if I don't do an update() after a
modification)
If you rpint the value that is evaluated in the condition, that should be
the value drools sees... But I am not an expert in JVM, so I could be wrong.
Regards,
Frank
marc wrote:
>
> I was using only one fireAllRules() after insert(message) and not
> fireUntilHalt(). But is should be enough : as the rule change & update the
> fact, the rule is applied again (10 seconds later, and not 1second).
>
> With fireUntilHalt() the rule work fine (and without timer)... but it
> burns the CPU (the java process reach 50% on a bi-proc) while a simple
> call to fireAllRues() after the timer update use nothing... This doesn't
> make sense to me because the drools engine is only notified of a fact
> modification only 1 time per second (the timer update), so it should only
> fire all rules a this moment and that all (just like a fireAllRules()
> after the update(SimpleClock) does), so why does it takes so much CPU ? I
> can post the code but I should open a other thread because it not the same
> "problem" ?
>
About adding log to trace the values of endDate, the traces show
correct
values. But it doesn't trace the value viewed by the drools engine itself
wich could be different (just as if I don't do an update() after a
modification)
> Marc
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
7:30 p.m.
Upgrade to 5.2M1 and the CPU overuse problem goes away.
--- On Wed, 3/30/11, marc <marc.strabin(a)gmail.com> wrote:
From: marc <marc.strabin(a)gmail.com>
Subject: Re: [rules-users] The update function inside a rule
To: rules-users(a)lists.jboss.org
Date: Wednesday, March 30, 2011, 5:47 AM
I was using only one fireAllRules()
after insert(message) and not
fireUntilHalt(). But is should be enough : as the rule
change & update the
fact, the rule is applied again (10 seconds later, and not
1second).
With fireUntilHalt() the rule work fine (and without
timer)... but it burns
the CPU (the java process reach 50% on a bi-proc) while a
simple call to
fireAllRues() after the timer update use nothing... This
doesn't make sense
to me because the drools engine is only notified of a fact
modification only
1 time per second (the timer update), so it should only
fire all rules a
this moment and that all (just like a fireAllRules() after
the
update(SimpleClock) does), so why does it takes so much CPU
? I can post the
code but I should open a other thread because it not the
same "problem" ?
About adding log to trace the values of endDate, the traces
show correct
values. But it doesn't trace the value viewed by the drools
engine itself
wich could be different (just as if I don't do an update()
after a
modification)
Marc
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:57 p.m.
Okay, understood, thanks for your explanations !
I hope the timer function will be fix in the next official release (I know,
I don't need it in the sample, but for others, more complex, rules...)
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/The-update-function-i...
Sent from the Drools - User mailing list archive at Nabble.com.
4774
days inactive
4777
days old
12 comments
5 participants
participants (5)
-
FrankVhh -
Greg Barton -
marc -
Marc Strabin
-
Wolfgang Laun