4:52 a.m.
Dear contributors,
this rule is expected to match a sequence of 2 consecutive events:
rule "test"
when
// a)
$ev1 : LocalizationEvent( type == TYPE.HINT, $target : target )
from entry-point "events/localization"
$ev2 : LocalizationEvent( type == TYPE.HINT, target == $target, this
after $ev1 ) from entry-point "events/localization"
// b)
// Ev1 directly followed by ev2: no other HINT in between
not( LocalizationEvent( type == TYPE.HINT, target == $target, this
after $ev1, this before $ev2 ) from entry-point "events/localization" )
then
do()
end
The second event is interpreted as a "confirmation" of the first event (a).
No other (deviating) event is allowed between them (b). With this
restriction
in place, the rule requires a sequence of 3 input events for activation,
otherwise
2 events are sufficient (as expected). The events are ordered correctly and
it is
not obvious, why a third event is needed since the interval between ev1 and
ev2 is
closed ? This leads to an unnecessary delay in rule activation.. How could
this be
avoided and are there other approaches to match a concrete event sequence
pattern ?
Many thanks
Jaro
--
View this message in context:
http://drools.46999.n3.nabble.com/Matching-consecutive-events-tp4018980.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
4:22 p.m.
See below.
On 01/08/2012, jpullmann <jaroslav.pullmann(a)fit.fraunhofer.de> wrote:
Dear contributors,
this rule is expected to match a sequence of 2 consecutive events:
rule "test"
when
// a)
$ev1 : LocalizationEvent( type == TYPE.HINT, $target : target )
from entry-point "events/localization"
$ev2 : LocalizationEvent( type == TYPE.HINT, target == $target,
this
after $ev1 ) from entry-point "events/localization"
// b)
// Ev1 directly followed by ev2: no other HINT in between
not( LocalizationEvent( type == TYPE.HINT, target == $target, this
after $ev1, this before $ev2 ) from entry-point "events/localization" )
then
do()
end
The second event is interpreted as a "confirmation" of the first event (a).
No other (deviating) event is allowed between them (b). With this
restriction
in place, the rule requires a sequence of 3 input events for activation,
Why do you think that three events are necessary? The "not" CE is the
negated existence quantifier - hence, there is no third event.
-W
otherwise
2 events are sufficient (as expected). The events are ordered correctly
and
it is
not obvious, why a third event is needed since the interval between ev1
and
ev2 is
closed ? This leads to an unnecessary delay in rule activation.. How could
this be
avoided and are there other approaches to match a concrete event sequence
pattern ?
Many thanks
Jaro
--
View this message in context:
http://drools.46999.n3.nabble.com/Matching-consecutive-events-tp4018980.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:47 a.m.
Welcome back, Wolfgang! I really missed your timely responses...
The amount of 3 events needed for activation is not an assumption, but a
fact.
When using the NOT-clause the rule triggers first at the arrival of a 3rd
event (HINT),
otherwise at the second. There is no further processing (retraction)
applied.
Thank you
Jaro
--
View this message in context:
http://drools.46999.n3.nabble.com/Matching-consecutive-events-tp4018980p4...
Sent from the Drools: User forum mailing list archive at Nabble.com.
8:53 a.m.
May be something with the internal clock and timestamps assigned as events dates and
inclusive (or not I don't remember) bounds in after/before operators evaluation ... in
short, I am not sure of the expected result if all your event (or 2 among your 3 events)
have the same event date.
But apart from that, may be you can implement a Listener (on "insert" callback)
that maintains an explicit insertion order directly inside the event. This way, no need to
use complex LHS to test that an event is directly preceeded by another.
9:06 a.m.
Hi Jaro,
This might be a side effect of the temporal reasoning algorithm when
using unbounded intervals like you are doing (i.e., using before and after
operators without an interval parameter). Assuming this is what is
happening, the activation is probably scheduled, but it only happens when
the next activity is about to happen inside the session.
With the current version, I can only suggest two workarounds. Either:
* Use straight relational operators in your rule (>, <). E.g.:
$ev2 : LocalizationEvent( ..., timestamp > $ev1.timestamp ) ...
* Or, try to use bounded temporal operators. E.g.:
$ev2 : LocalizationEvent( ... this after[0,60s] $ev1 ) ...
We know it is not ideal, and for the next Drools release we are
implementing explicit sequence operators where you will be able to just
define [strict] sequencing. E.g.:
when
$ev1 : LocalizationEvent( ... ) =>
$ev2 : LocalizationEvent( ... )
then
...
Details here:
https://community.jboss.org/wiki/EventSequencing#4_Definition_Sequence_Co...
Edson
On Wed, Aug 1, 2012 at 5:52 AM, jpullmann <
jaroslav.pullmann(a)fit.fraunhofer.de> wrote:
Dear contributors,
this rule is expected to match a sequence of 2 consecutive events:
rule "test"
when
// a)
$ev1 : LocalizationEvent( type == TYPE.HINT, $target : target )
from entry-point "events/localization"
$ev2 : LocalizationEvent( type == TYPE.HINT, target == $target,
this
after $ev1 ) from entry-point "events/localization"
// b)
// Ev1 directly followed by ev2: no other HINT in between
not( LocalizationEvent( type == TYPE.HINT, target == $target, this
after $ev1, this before $ev2 ) from entry-point "events/localization" )
then
do()
end
The second event is interpreted as a "confirmation" of the first event
(a).
No other (deviating) event is allowed between them (b). With this
restriction
in place, the rule requires a sequence of 3 input events for activation,
otherwise
2 events are sufficient (as expected). The events are ordered correctly
and
it is
not obvious, why a third event is needed since the interval between ev1
and
ev2 is
closed ? This leads to an unnecessary delay in rule activation.. How could
this be
avoided and are there other approaches to match a concrete event sequence
pattern ?
Many thanks
Jaro
--
View this message in context:
http://drools.46999.n3.nabble.com/Matching-consecutive-events-tp4018980.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
4:40 a.m.
Wolfgang, Vincent, Edson, many thanks for your support!
A numeric comparison of the the event timestamps did the trick.
Now I am wondering, whether using simple arithmetic operators
instead of explicit (built-in) temporal operators might impact the
automatic life-cycle management and cleanup of timed events.
Are these rules treated equally and do the involved events automatically
expire (based on their temporal annotations) ?
Best regards
Jaroslav
--
View this message in context:
http://drools.46999.n3.nabble.com/Matching-consecutive-events-tp4018980p4...
Sent from the Drools: User forum mailing list archive at Nabble.com.
12:22 p.m.
To paraphrase Robert Z., "Time is just another four letter word" ;-)
Clocks are just integers, incremented by Chronos, or some other god.
If the god is lazy, it'll run slowly; if the god is eager, it'll be
fast. You can be your own god (and use a pseudo-clock). You can start
with the Big Bang, your birthday, or with the recording time of A
Bigger Bang. You don't even need to count ticks of your time: you can
count sheep, too. The only rule you should obey is: never go back in
time.
Cheers
Wolfgang
On 07/08/2012, jpullmann <jaroslav.pullmann(a)fit.fraunhofer.de> wrote:
Wolfgang, Vincent, Edson, many thanks for your support!
A numeric comparison of the the event timestamps did the trick.
Now I am wondering, whether using simple arithmetic operators
instead of explicit (built-in) temporal operators might impact the
automatic life-cycle management and cleanup of timed events.
Are these rules treated equally and do the involved events automatically
expire (based on their temporal annotations) ?
Best regards
Jaroslav
--
View this message in context:
http://drools.46999.n3.nabble.com/Matching-consecutive-events-tp4018980p4...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4542
days inactive
4548
days old
6 comments
4 participants
participants (4)
-
Edson Tirelli -
jpullmann -
Vincent LEGENDRE -
Wolfgang Laun