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<tviessm...@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@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
