Re: [rules-dev] time behaviour, suggested changes
On 18/04/2012, Mark Proctor <mproctor(a)codehaus.org> wrote:
Currenty timer initialisation is not defined very well and rules
don't
obey salience, which can make them harder to use.
Agenda interaction and scheduling:
1) Rule activations are added to the agenda like any other rule.
2) When the rule is popped from the agenda, instead executing the RHS
the timir started is started.
I suppose this should read "...the timer is started." More precisely:
"...the timer for the <initial delay> is started.
Here I propose this amendment: If the <initial delay> is 0, the RHS is
executed right away, and the timer for <repeat interval> is started,
if defined. (Thus, a rule with "timer(int: 0s)" behaves like a rule
without.)
3) Each time the timer is triggered the rule is added to the agenda
and
continues to obey salience. This time when the rule is popped from the
agenda it executes the consequence.
Every effort is made to avoid drift, i.e., the timer for another
<repeat interval> is restarted right away, before adding the rule to
the agenda.
Fact modification behaviour:
Modify on scheduled rules currently retriggers the initial delay, if
that's 0 it can cause the rule to refire straight away, which I believe
never wanted.
Agreed. Also, once set up and repeatedly firing, a rule with a timer
is typically intended to stick to its <repeat interval>. All the cases
I've seen (and I've seen a lot over the last 25 years) do not fiddle
with this interval. If a periodic task needs to be changed, it isn't
just the <repeat interval> but also the action, which (with Drools)
would mean another rule altogether.
-W
1) If the timer expression does not used any modified fields, it
should
not be re-scheduled.
2) Reschedule should be done for the repeat period only, we shoud not
trigger another delay.
3) The first time it is scheduled after the period has changed it should
subtract the amount for time difference left over from the last period.
For those that want timer rules to fire independant of the agenda, we
will probably add an annotation to specify the rule is not to be handled
via the agenda. This will give behaviour roughly to what we have now.
One reason why this change is important is with the upcoming algorithm
change for lazy rete. We need to use the agenda and rule priorities to
determine when to evaluate rules. Any rules not handled by the agenda
will have to be left eager, so there are significant performance gains
from this, as well as userbility gains from having timer rules that
still obey salience.
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev