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:
Edson
On Wed, Aug 1, 2012 at 5:52 AM, jpullmann
<jaroslav.pullmann@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com