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