[rules-users] Consequence Exception with too many events
Davide Sottara
dsotty at gmail.com
Sat May 4 13:23:43 EDT 2013
No, for a CEP engine this is one of the most serious types of problems.
It's possible for an engine to be overloaded, but if this is the behavior,
a sporadic event burst could be used to blow up the execution.
I suspect slower CPUs may incur this problem at much lower
insertion/expiration rates,
I'll raise a killer JIRA and request a more graceful fail mechanism in 5.x.
Good news is, 6.x may be able to deal with these issues much better.
Thanks!
On 05/04/2013 09:59 AM, Jason Barto wrote:
> Wolfgang,
> I'd agree with you although I will continue to research further. If
> it is as you suggest - a race condition - I would think a more
> appropriate reaction of the system would be to emit a warning that
> events are expiring before they can be considered by the rules engine,
> although I would think that this is a use case which does not see much
> real life execution. Thank you very much for your time and input into
> this matter, it's been educational.
>
> Sincerely,
> Jason
>
> On Saturday, May 4, 2013, Wolfgang Laun wrote:
>
> I can confirm that (using 5.5.0) this NPE occurs predictably with a
> limit of 500000.
>
> It looks like a race condition to me - at least that is what line
> DefaultAgenda.java:1319 suggests. Possibly it is due to automatic
> retraction "overtaking" rule firing, since the latter tends to take
> much, much longer than the ~10sec the mere insertion of 500K events
> takes on my system.
>
> 500,000 inserted in 10s means 50,000/s, and that, in turn, implies
> 50,000 retractions per second. 30s after the last insertion, only
> ~90,000 firings have taken place. (I added a printout of the counter's
> total after the Thread.sleep().)
>
> It's interesting to experiment with the @expires value: Everything
> else remaining the same, a setting of @expires(10s) will let the
> firings complete without a NPE.
>
> So, I'm back to my surmise: a race condition, due to expiry being cut
> too short to cope with the system load. I'd still classify this as a
> Drools bug: it should notice that it is being overtaxed and/or
> destabilizing itself.
>
> -W
>
>
> On 04/05/2013, Jason Barto <jason.p.barto at gmail.com> wrote:
> > Wolfgang,
> > thank you for your prompt reply. After further work with my
> code I think
> > the culprit may have either been the setting of the event
> expiration time
> > to 1s OR that I was using session.update to insert a new counter
> object;
> > but maybe not. I cleaned up my code in order to send it out.
> In doing so
> > I also downloaded the official Drools 5.5 distribution (in the
> previous
> > example I was using the libraries packaged with BRMS). Between
> the code
> > cleanup and the use of the official distro I'm no longer
> experiencing a
> > Consequence Exception.
> >
> > That being said I am still experiencing a NPE when a high
> iteration count.
> > If you take a look at Drools5FusionEval.java, around line 51
> you'll see a
> > variable 'eventLimit'. If set to 500000 it seems to pretty
> reliably kick
> > out the following NPE:
> >
> > Exception in thread "Thread-1" java.lang.NullPointerException
> > at
> >
> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1319)
> > at
> >
> org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> > at
> >
> org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1434)
> > at
> >
> org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:755)
> > at
> >
> org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:731)
> > at
> >
> org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:247)
> > at
> drools5fusioneval.Drools5FusionEval$1.run(Drools5FusionEval.java:47)
> >
> > As I've said I'm still very new to Drools and trying to
> understand better
> > how it does what it does - any information that anyone can
> provide to help
> > me understand why the above error is being experienced would be
> greatly
> > appreciated.
> >
> > Source code and rules are attached.
> >
> > Sincerely,
> > Jason
> >
> >
> > On Sat, May 4, 2013 at 7:58 AM, Wolfgang Laun
> > <wolfgang.laun at gmail.com>wrote:
> >
> >> Works for me (5.5.0, 5.4.0) - at least based on the code you've
> posted
> >> which (apart from the omitted getters and setters) isn't the
> one you've
> >> been running, and so you may have changed or omitted something
> >> that's essential.
> >>
> >> The full stack dump might shed some more light on this, and the
> full and
> >> true code of the rule RHS whre the NPE is caused.
> >>
> >> -W
> >>
> >> On 04/05/2013, Jason Barto <jason.p.barto at gmail.com> wrote:
> >> > I am new to Drools (Expert and Fusion) and have been reading
> through
> >> > the
> >> > materials over the last few days. After going through some
> of the
> >> tutorial
> >> > code I wrote a very quick and dirty to perform a base
> assessment of the
> >> > speed of Fusion / Expert. My code is below. The strange
> thing I'm
> >> > currently receiving is, if I insert 100k events the test
> completes
> >> > successfully, if I insert 150k events, I receive a
> ConsequenceException
> >> > caused by an NPE. Being new to Drools I must be doing
> something wrong,
> >> can
> >> > anyone please provide some guidance?
> >> >
> >> > (Main function)
> >> > Counter cc = new Counter ();
> >> > session.insert (cc);
> >> > for (int i = 0; i < 150000; i++) {
> >> > entryPoint01.insert (new MyEvent ());
> >> > }
> >> >
> >> > (Counter Class)
> >> > public class Counter {
> >> > private long total = 0;
> >> > // get / set total
> >> > public void addValue (int val) {
> >> > total += val;
> >> > }
> >> > }
> >> >
> >> > (MyEvent Class)
> >> > public class MyEvent {
> >> > private int value = 1;
> >> > // get / set value
> >> > }
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20130504/ec8b74fc/attachment-0001.html
More information about the rules-users
mailing list