1:04 p.m.
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
3:44 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:08 p.m.
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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:29 p.m.
I assumed you were quoting from some documentation.
Mark
On 20 Jun 2013, at 17:08, Wolfgang Laun <wolfgang.laun(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:55 p.m.
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(a)codehaus.org> wrote:
I assumed you were quoting from some documentation.
Mark
On 20 Jun 2013, at 17:08, Wolfgang Laun <wolfgang.laun(a)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(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:17 a.m.
Added to
Chapter-LanguageReference<https://github.com/droolsjbpm/drools/tree/ma...
*Section-Rule.xml* on master.
-W
On 20 June 2013 22:55, Wolfgang Laun <wolfgang.laun(a)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(a)codehaus.org> wrote:
> I assumed you were quoting from some documentation.
>
> Mark
>
> On 20 Jun 2013, at 17:08, Wolfgang Laun <wolfgang.laun(a)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(a)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(a)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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
9:05 p.m.
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/jav...
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(a)gmail.com> wrote:
Added to Chapter-LanguageReference / Section-Rule.xml on master.
-W
On 20 June 2013 22:55, Wolfgang Laun <wolfgang.laun(a)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(a)codehaus.org> wrote:
I assumed you were quoting from some documentation.
Mark
On 20 Jun 2013, at 17:08, Wolfgang Laun <wolfgang.laun(a)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(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:01 p.m.
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(a)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/jav...
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(a)gmail.com> wrote:
Added to
Chapter-LanguageReference<https://github.com/droolsjbpm/drools/tree/ma...
*Section-Rule.xml* on master.
-W
On 20 June 2013 22:55, Wolfgang Laun <wolfgang.laun(a)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(a)codehaus.org> wrote:
>
>> I assumed you were quoting from some documentation.
>> Mark
>>
>> On 20 Jun 2013, at 17:08, Wolfgang Laun <wolfgang.laun(a)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(a)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(a)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(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7 p.m.
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(a)lists.jboss.org [mailto:rules-users-bounces@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@codehaus.org<mailto:mproctor@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/jav...
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@gmail.com<mailto:wolfgang.laun@gmail.com>> wrote:
Added to
Chapter-LanguageReference<https://github.com/droolsjbpm/drools/tree/ma...
/ Section-Rule.xml on master.
-W
On 20 June 2013 22:55, Wolfgang Laun
<wolfgang.laun@gmail.com<mailto:wolfgang.laun@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@codehaus.org<mailto:mproctor@codehaus.org>> wrote:
I assumed you were quoting from some documentation.
Mark
On 20 Jun 2013, at 17:08, Wolfgang Laun
<wolfgang.laun@gmail.com<mailto:wolfgang.laun@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@codehaus.org<mailto:mproctor@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@gmail.com<mailto:wolfgang.laun@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@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
8:07 p.m.
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(a)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(a)lists.jboss.org
[mailto:rules-users-bounces@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@codehaus.org<mailto:mproctor@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/jav...
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@gmail.com<mailto:wolfgang.laun@gmail.com>> wrote:
Added to
Chapter-LanguageReference<https://github.com/droolsjbpm/drools/tree/ma...
/ Section-Rule.xml on master.
-W
On 20 June 2013 22:55, Wolfgang Laun
<wolfgang.laun@gmail.com<mailto:wolfgang.laun@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@codehaus.org<mailto:mproctor@codehaus.org>> wrote:
I assumed you were quoting from some documentation.
Mark
On 20 Jun 2013, at 17:08, Wolfgang Laun
<wolfgang.laun@gmail.com<mailto:wolfgang.laun@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@codehaus.org<mailto:mproctor@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@gmail.com<mailto:wolfgang.laun@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@lists.jboss.org<mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
9:28 p.m.
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(a)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(a)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(a)lists.jboss.org
> [mailto:rules-users-bounces@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@codehaus.org<mailto:mproctor@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/jav...
>
>
> 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@gmail.com<mailto:wolfgang.laun@gmail.com>> wrote:
>
>
> Added to
>
Chapter-LanguageReference<https://github.com/droolsjbpm/drools/tree/ma...
> / Section-Rule.xml on master.
> -W
>
> On 20 June 2013 22:55, Wolfgang Laun
> <wolfgang.laun@gmail.com<mailto:wolfgang.laun@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@codehaus.org<mailto:mproctor@codehaus.org>> wrote:
> I assumed you were quoting from some documentation.
> Mark
>
> On 20 Jun 2013, at 17:08, Wolfgang Laun
> <wolfgang.laun@gmail.com<mailto:wolfgang.laun@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@codehaus.org<mailto:mproctor@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@gmail.com<mailto:wolfgang.laun@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@lists.jboss.org<mailto:rules-users@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3945
days inactive
3963
days old
10 comments
3 participants
participants (3)
-
Mark Proctor -
Thomas Grayson -
Wolfgang Laun