[rules-users] Timers and fireAllRules

[Wolfgang Laun]

 Added to Chapter-LanguageReference<https://github.com/droolsjbpm/drools/tree/master/drools-docs/drools-expert-docs/src/main/docbook/en-US/Chapter-LanguageReference>/
*Section-Rule.xml* on master.
-W


On 20 June 2013 22:55, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:

> 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/20130622/ff7fc995/attachment.html