Unfortunately I was never able to reproduce this in a self-contained test.
Currently, I have about 100 rules and I can't figure out what combination of
events are causing it. Instead, I tried to clean up the symptoms of the issue
by overriding the classes that were throwing the uncaught NPE and handling it
properly with a logged error message. Interestingly enough, it doesn't seem to
affect functionality once it is caught properly, at least that I can tell.
Some observations, though:
- I have equality assertion type turned on
- many if my events/facts are declared in the rules and are not pojos.
- it has to do with modify/updates from rule consequences.
- if I replace all of my modify's with a retract + copy over to new object +
insert, then the issues seems to either go away or become less frequent.
- annotating objects with the property reactive annotation makes it happen
much, much less frequently
- on an unrelated note, there is a race condition in the JIT compilation. If a
fact is retracted at just the right time, it throws a NPE during the jitting
process.
Sent from my iPhone
> On Nov 20, 2013, at 11:41 AM, Davide Sottara <dso...@gmail.com> wrote:
>
> Jonathan,
> thanks for the hints. This seems to be a critical bug, could you please
> provide some additional details
> or, ideally, the unit test that you are running?
> It would be really appreciated
> Thanks
> Davide
>
>> On 11/18/2013 04:28 PM, Jonathan Knehr wrote:
>> I only use it from a single thread. What I meant was that for example, for
>> the same set of rules, the issue never was created with, say, 20 iterations
>> of inserting the same facts/events over again. Instead, it was more on the
>> order of a few hundred thousand before the NPEs started showing up.
>> Literally running the same unit test in a loop until it NPE'ed. But all from
>> a single thread...
>>
>> Sent from my iPhone
>>
>>> On Nov 18, 2013, at 4:00 PM, Davide Sottara <dso...@gmail.com> wrote:
>>>
>>> Jonathan,
>>> Drools 5.5 was never meant to be multi-threaded. 5.6 tries to put a few
>>> patches here and there, 6.0 is going in that direction and 6.1 will
>>> hopefully solve the problem.
>>> Thanks for the hint to the "internal hash table", it may give us ideas
>>> on what to test next. However, if you or anyone could ever reproduce the
>>> issue and submit a test
>>> case that would be REALLY appreciated
>>> Thanks
>>> Davide
>>>
>>>> On 11/18/2013 12:04 PM, Jonathan Knehr wrote:
>>>> In the past I've tried to reproduce a similar issue.
>>>>
>>>> Don't know if this will help, but I could not reproduce the NPEs without
>>>> running a large amount of events into the rule engine. A small unit test
>>>> never reproduced these issues for me, which made it harder. Not sure about
>>>> this issue in particular, but other ones I've seen seem to be related to
>>>> the internal hash table eventually misplacing objects. This created all
>>>> sorts of odd symptoms, namely NPEs all over the place in random drools
>>>> classes. But I think all of these are just symptoms of the same bug at the
>>>> core level somewhere. They all are related IMO.
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Nov 18, 2013, at 9:48 AM, Davide Sottara <dso...@gmail.com> wrote:
>>>>>
>>>>> I tried to reproduce the problem, with no success.
>>>>> Could you please create a self-contained unit test?
>>>>> If confirmed, I'll fix the problem as soon as possible
>>>>> Thanks
>>>>> Davide
>>>>>
>>>>>> On 11/14/2013 04:48 AM, abr wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> I tried to switch from 5.5.0.Final to 5.6.0.CR1 and got a null pointer
>>>>>> exception in the evaluation of the after evaluator.
>>>>>> (Exact method is:
>>>>>> /org.drools.base.evaluators.AfterEvaluatorDefinition.AfterEvaluator.evaluate(InternalWorkingMemory,
>>>>>> InternalReadAccessor, InternalFactHandle, InternalReadAccessor,
>>>>>> InternalFactHandle)/ )
>>>>>>
>>>>>> When debugging, the exception occurs at the very first line of the
>>>>>> method,
>>>>>> in:
>>>>>> / if ( extractor1.isNullValue( workingMemory, handle1.getObject() )
>>>>>> ||
>>>>>> extractor2.isNullValue( workingMemory, handle2.getObject() ) ) {
>>>>>> return false;
>>>>>> }
>>>>>> /
>>>>>> The cause of the exception is that handle1 is null.
>>>>>>
>>>>>> The rule where the exception occurs looks like:
>>>>>> / MyFact(
>>>>>> fromdate before[ 0d ] $min,
>>>>>> ( todate == null || todate after[ 0d ] $max ) )
>>>>>> /
>>>>>>
>>>>>> When the exception occurs, /MyFact.fromdate/ is not null, /$min/ is not
>>>>>> null, /MyFact.todate/ is null, /$max/ is not null.
>>>>>> In AfterEvaluator.evaluate : /extractor1/ refers to /MyFact.todate/,
>>>>>> /extractor2/ refers to /$max/, /handle1/ is null, /handle2/ refers to the
>>>>>> fact including the attribute to which /$max/ variable is bound to.
>>>>>>
>>>>>> Of course, this worked fine in 5.5.0.Final.
>>>>>> I couldn't test this out in Drools 6.0.0.CR5 because I have dependencies
>>>>>> to
>>>>>> drools-spring JAR that does not exist anymore in 6.0.0.CR5.
>>>>>>
>>>>>> Is it simple to fix this problem?
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Best,
>>>>>> Alexis
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://drools.46999.n3.nabble.com/5-6-0-CR1-gives-a-NullPointerException-in-after-evaluator-tp4026780.html
>>>>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>>>>> _______________________________________________
>>>>>> rules-users mailing list
>>>>>> rules-users@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> rules-users@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>> _______________________________________________
>> rules-users mailing list
>> rules-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
