Thank you, Edson.
I've thought about it. There are some inconsistencies in the application
integrating my application. Therefore using sliding windows is kind of
problematic. There for I'm using the events timestamps as a compromise ...
I know, its very critizisable, but I can't change it.
Thanks anyway :)
For a pair of events, the performance will be the same with
before/after. If you have more than 2, though, best would be to use
sliding windows.
Edson
2010/9/14 Tina Vießmann<tviessmann(a)stud.hs-bremen.de>:
> Hi,
>
> I've mentioned the test case I'm working on before. It's: If a certain
value
> exceeds a limit more than X times within Y minutes/hours, do something.
> ~> Count = X , time = Y
>
> During a talk with other developers it came up that by intuition the men
> would have chosen a other approach than the women. We can not agree if in
> Drools both approaches are the same in performance or if one is more
> performant.
>
> Male approach: If a new event with a limit violation is received, check if
> within the last time Y already X events with limit violations are contained
> in the knowledge base .
>
> Female approach: If a new event with a limit violation is received, check if
> the following events contain X events with limit violation. This is limited
> to a monitoring time of maximal Y. (If there have been X events registered,
> before the time Y is elapsed, the window will be closed right away.)
>
> In code with Y = 1h it would be:
> Male:
>
> // determine new event as $triggeringEvent
> $otherEvent : Value (this before[0ms,1h] $triggeringEvent)
>
> Female:
>
> // determine event that opened the window as $triggeringEvent
> $otherEvent : Value (this after[0ms,1h] $triggeringEvent)
>
> This is just a extract so that that the comments are in fact meaningless.
> The focus lies on before and after.
>
>
> Is one solution more efficient?
>
>
> Thanks! :)
> Tina
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
>