[rules-users] Timers and fireAllRules

Tue Jul 2 14:07:08 EDT 2013

Timers not continuing to fire after fireUntilHalt returns makes this
feature unusable for us, too. :-[

We see timer-controlled firing as a sustained firing, maintaining a
sort of "frozen" state. If some process is tied to Time, halting a
rule engine is a "minor event".

-W

On 02/07/2013, Thomas Grayson <tgrayson at bluemetal.com> wrote:
> I'm grateful for the clarification that the timer behavior is changing in
> Drools 6.  I was planning on exploiting the Drools 5 behavior to fire
> certain rules asynchronously at intervals using a timer, even when the
> engine was otherwise idle.  I don't want to use fireUntilHalt because I need
> to make numerous updates to facts in a batch in Java code, and I don't want
> any rules to fire prematurely.  To prepare for Drools 6, then, it looks like
> I should use Java to implement the timer, update the working memory, and
> call fireAllRules.  I'd prefer to be able to specify this declaratively in
> the DRL file as I can now in Drools 5, but since I want to future-proof my
> code I'll need a different approach.
>
> Best wishes,
> Tom
>
> From: rules-users-bounces at lists.jboss.org
> [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Wolfgang Laun
> Sent: Monday, June 24, 2013 4:02 PM
> To: Rules Users List
> Subject: Re: [rules-users] Timers and fireAllRules
>
> You just make sure that the documentation for 5.x remains as I've added it,
> and that it is updated accordingly for the 6.x Expert manual.
> I don't think that the behaviour in 5.x when fireAllRules() is called and
> repeating timers execute their tasks even when the Engine is idle is evil.
> The general flow of logic is consistent even though some executions happen
> later compared to what would happen when running in fireUntilHalt.
> But you can indeed uphold the position that any timer activity is in
> conflict with the Engine being suspended after fireAllRules() returns. But
> what should be the consequence? Delay the return? Terminate the timers?
> Disallow timers being launched in a run initiated by fireAllRules()? Let's
> hope that 6.x reacts cleanly...
> -W
>
>
>
> On 24 June 2013 21:05, Mark Proctor
> <mproctor at codehaus.org<mailto:mproctor at codehaus.org>> wrote:
> btw sorry about the confusion. The reason was we have changed the behaviour
> in 6, and in the mean time I'd forgotten what the exact behaviour was in 5.
>
> In 6.x there is no async behaviour, for fireAllRules,  all action happens in
> the user thread.  So there will be no rule firing if fireAllRules (passive
> mode) is not called, or you are not using fireUntilHalt (reactive mode).
>
> There have been several discussion on IRC, and the conclusion was were very
> uncomfortable with async operations of timers, in passive mode. If people
> want reactive behaviour, they should use the engine in reactive mode, if
> they want passive behaviour, they should use the engine in passive mode.
>
> Timers  are no longer part of  Agenda, and instead we have a TimerNode that
> lives in the network. It's role is simply to control tuple propagation. The
> code is a lot simpler and more isolated than 5.x, this is also very helpful
> (if not necessary) in the multi-core work we plan to do.
> https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/phreak/PhreakTimerNode.java
>
>
> We do think there may be some future use cases for a mixed hybrid/passive
> execution mode. Where some rules are passive, some reactive, but we'd rather
> that we found a way to do this declaratively.
>
> Mark
>
> On 22 Jun 2013, at 07:17, Wolfgang Laun
> <wolfgang.laun at gmail.com<mailto:wolfgang.laun at gmail.com>> wrote:
>
>
> 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org<mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org<mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org<mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org<mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org<mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>