Thanks for your reply.
I tried around and found out that the main problem seemed to be the multithreaded setup combined with fireUntilHalt().
When I switched to single threaded and using fireAllRules() every 1000 events everything works fine. No race conditions. (And no freezing when inserting events (I didn't describe this problem in my previous email but after a few 1000 event insertions Drools sometimes froze during "entryPoint1.insert(obj)" and didn't recover.))
I'm able to handle the 50k events within 4 seconds now with that I'm quite happy :)
>> The Alarm tied to some eventValue is OK. But I'd try and accumulate the matching events "manually" into a list kept in the Alarm fact
Does this work with Events/Facts that have an expiration Date? Would the event/fact be automatically removed from this list when it expires?
Gesendet: Montag, 20. Januar 2014 um 22:02 Uhr
Von: "Wolfgang Laun" <wolfgang.laun@gmail.com>
An: "Rules Users List" <rules-users@lists.jboss.org>
Betreff: Re: [rules-users] Fusion CEP Design problem / Race Condition
The test (as you describe it) isn't really reproducing what will
happen in reality. A burst of 5000 events (almost) at the same time
followed by a lull of 5sec isn't quite like a scenario of 25-50k per
minute.
The Alarm tied to some eventValue is OK. But I'd try and accumulate
the matching events "manually" into a list kept in the Alarm fact, and
I'd even try and do the retraction by comparing the timestamp of the
oldest with the timestamp of a new arrival. You can easily handle the
situation when 30 is reached. (You may have to decide when this is
retriggered, i.e., the count falls below 30 and then exceeds 30 once
more.)
A little consideration should also be given to the number of different
eventValues. If these values are from a stable set, I don't see any
problems.
-W