-W_______________________________________________On 20 June 2013 22:55, Wolfgang Laun <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> wrote:I assumed you were quoting from some documentation.MarkOn 20 Jun 2013, at 17:08, Wolfgang Laun <wolfgang.laun@gmail.com> wrote:-WYou 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.
_______________________________________________On 20 June 2013 15:44, Mark Proctor <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> 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
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users