[rules-users] Drools 5.6

[Jonathan Knehr]

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 <jonathan.knehr at gmail.com> 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 <dsotty at gmail.com> 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 <dsotty at gmail.com> 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
>>>>> rules-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>> 
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users