Turns out that if I annotate the pojos that are being modified by some of the rules with the PropertyReactive annotation, then every single NPE disappears.
> On Sep 18, 2013, at 4:15 PM, Jonathan Knehr <[email protected]> wrote: > > I'll see if I can't try again to reproduce this as a unit test this week. > > Any rule that has a not/exist only has one in the entire rule, as the last > condition. Not currently, but in the past if I've commented out all of > not/exist conditions in all the rules, it would run without any exceptions. > > Additionally, I'm using salience quite heavily. I'm wondering if the salience > has to do something to do with these errors as well. I set the salience > (automatically) for every rule so that the firing order is the same as the > order they appear in the DRL file. > > Not using multi-thread. Assert behavior is set to equality. Everything else > is default. Not using windows or aggregators. As a matter of fact I'm not > using any special operators except for "not" and "exists". Everything is just > joining on facts/events. Have about 4-5 entry points where these facts are > held. > > The issue seems to never happen on an external, API insert. It seems to only > happen when a rules consequence inserts/modifies/updates/retracts. And even > then, it doesn't happen in a predictable manner. Although it is consistent, > so if I replay the same events the errors happen in the same exact sequence. > >> On Sep 18, 2013, at 4:01 PM, Davide Sottara <[email protected]> wrote: >> >> If confirmed, this would be EXTREMELY serious and must be fixed in 5.6 >> Final. >> Could you open a JIRA ticket for this? >> We'd really need a reproducer for this issue, without some additional >> context it will be extremely hard to point to the right lines of code. >> >> For example, >> is it sufficient for your rule to have one exists/not, or do you need >> more than one in combination? >> Are you using CEP and/or sliding windows? >> Multiple threads? >> What do you mean by "complex retractions" >> and so on... >> >> Thank you in advance for all the help you can provide >> Davide >> >>> On 09/18/2013 10:29 AM, Jonathan Knehr wrote: >>> Tried with the 5.6 snapshot just now. >>> >>> Same/similar issues. >>> >>> NPEs in RightTupleIndexHashTable. >>> ClassCastExceptions from many of the InternalReadAccessor generated >>> bytecode classes. >>> NPEs in MvelContraint class. >>> >>> I'm replaying the exact same series of events that I did for the 5.5 run. >>> >>> Could you point me to where you think the origin of the corruption occurs? >>> I have breakpoints where the exceptions are thrown, but this is long after >>> the data structure was originally corrupted. It would help me try my hand >>> at debugging the issue for you further. >>> >>> Thanks in advance!! >>> Jonathan >>> >>>> On Sep 18, 2013, at 1:19 PM, Davide Sottara <[email protected]> wrote: >>>> >>>> Did you try to run the code with 5.6.0-SNAPSHOT? It's now available from >>>> RHT maven repositories.. >>>> the official release is still waiting for the fix of a few more bugs, >>>> but the tuple index one should have >>>> already been fixed. If not, it would be critical to include it in the >>>> final version >>>> Thanks >>>> Davide >>>> >>>>> On 09/18/2013 09:16 AM, Jonathan Knehr wrote: >>>>> When is 5.6 going to be officially released? >>>>> >>>>> There are many critically buggy things going on in 5.5 where the entire >>>>> RightTupleIndex is getting very corrupted. I still haven't been able to >>>>> produce a standalone unit test, but the issue always involves rules with >>>>> "exists" and "not" in combination with complex retractions. Never does it >>>>> happen with a few events, but when you run the scenarios over and over >>>>> again millions of times, eventually the index becomes so corrupt that >>>>> almost every single activation throws NPEs in MVEL, in the generated byte >>>>> code, and in the rete data structures themselves to the point where all >>>>> rule firing stops working. >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> _______________________________________________ >>>> rules-users mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> _______________________________________________ >>> rules-users mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
