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(a)gmail.com> wrote:
If confirmed, this would be EXTREMELY serious and must be fixed in
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.
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?
What do you mean by "complex retractions"
and so on...
Thank you in advance for all the help you can provide
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
> 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
> Thanks in advance!!
> On Sep 18, 2013, at 1:19 PM, Davide Sottara <dsotty(a)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
>> 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 mailing list
> rules-users mailing list
rules-users mailing list