[rules-users] Timers and fireAllRules

Wolfgang Laun wolfgang.laun at gmail.com
Thu Jun 20 16:55:31 EDT 2013


OK, and now? You can wrap it into a couple of docbook tags and add it to
the Expert manual, I'm not reserving the copyright ;-)
-W


On 20 June 2013 21:29, Mark Proctor <mproctor at codehaus.org> wrote:

> I assumed you were quoting from some documentation.
>
> Mark
>
> On 20 Jun 2013, at 17:08, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>
> You sound absolutely sibyllic. Which documentation will you update - I'm
> not aware of any documentation describing the behaviour of timers. What, in
> your opinion, was the "behaviour in an older version"? And what "older
> version" are you referring to anyway? I've ascertained that what I
> described is the behaviour in 5.1.1, 5.2.0, 5.3.0, 5.4.0 and 5.5.0.
>
> And: where is it written that execution tied to a repeating timer "must be
> constrained within fireAllRules?" I could make a very good case for arguing
> that RHS executions due to timer expiry aren't "firing" in the classic
> sense - that's just what happens when the LHS matches.
>
> -W
>
>
> On 20 June 2013 15:44, Mark Proctor <mproctor at codehaus.org> wrote:
>
>> We'll update the documentation, that was probably the behaviour in an
>> older version. The behaviour should not have rules async firing, unless
>> there is proper async controls, as with fireUntilHalt, otherwise the
>> firings must be constrained within fireAllRules.
>>
>> Mark
>> On 20 Jun 2013, at 12:04, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>
>> >    A rule controlled by a timer becomes active when it matches, and
>> >    once for each individual match. Its consequence is executed
>> >    repeatedly, according to the timer's settings. This stops as soon
>> >    as the condition doesn't match any more.
>> >
>> >    Consequences are executed even after control returns from a call
>> >    to fireUntilHalt(). Moreover, the Engine remains reactive to any
>> >    changes made to the Working Memory. For instance, removing a fact
>> >    that was involved in triggering the timer rule's execution causes
>> >    the repeated execution to terminate, or inserting a fact so that
>> >    some rule matches will cause that rule to fire. But the Engine is
>> >    not continually active, only after a rule fires, for whatever
>> >    reason. Thus, reactions to an insertion done asynchronously will
>> >    not happen until the next execution of a timer-controlled rule.
>> >
>> >    Disposing a session puts an end to all timer activity.
>> >
>> >    -W
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20130620/35e4e076/attachment.html 


More information about the rules-users mailing list