On 18/04/2012, Mark Proctor <mproc...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
