[rules-dev] time behaviour, suggested changes

[Wolfgang Laun]

On 18/04/2012, Mark Proctor <mproctor at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>