[rules-users] Timers and fireAllRules

Mark Proctor mproctor at codehaus.org
Mon Jul 8 15:28:15 EDT 2013 

There may be some compromises, that we can make available as an "internal" api for now,  that does not violate a passive system. Which I was going to hold off until after 6.0. By keeping it internal, it means people can use it now, and when we are happy with the psi and design, we can make it public. So people can use it now, but are aware the api may change.

6.0 has much stricter handling of threads, and has a better defined threading model. Too much in 5.x is vague, because it grew organically, it was not designed. These improvements are necessary for both thread safety and performance, while avoiding large global locks. We really need this, if we are to start exploiting multi-core machines in future releases, it simply is not possible with the lax Rete design. So I hope people understand, there is a bigger picture in our designs, that we trying to get to here - but it involves tightening up, simplifying and improving our codebase now.

In the Rete design, as the user thread,or the timer thread, can touch any part of the engine, this is a serious design limitations, that impacts thread safety and performance. In 6.x the user thread NEVER touches the beta network during insert/update/delete. The beta network is drive by the thread that calls fireAllRules, or the thread passed for fireUntilHalt. The timer doesn't actually evaluate the network any more, like it did in 5.x - due to thread isolation. Instead it notifies the beta thread to evaluate. That last bit is important, in a passive system there is no thread to notify, hence why the rule does not get evaluated. Further the system is oriented for batch executions now, so we don't really want rule evaluations done in the time thread, for a single timer event. Instead we want it to notify that it's ready to be evaluated, so that the beta thread can process it and other things as part of the batch for that rule.

What we might be able to do is externalise a timer callback, so the user can provider a handler that is invoked by the timer. Then it's up to the user if they wish the related rule(s) to be evaluated and fired. That last bit is already possible, as it's intrinsic to how 6.x works. the user then could setup their own external thread. This allows the passive system default, but wight he ability to selectively apply reactivity by the user.

Mark


On 2 Jul 2013, at 19:07, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:

> 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
>> 
>> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

More information about the rules-users mailing list