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-... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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 <dsotty(a)gmail.com&gt; 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-... >> Sent from the Drools: User forum mailing list archive at Nabble.com. >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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 <dsotty(a)gmail.com&gt; 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 <dsotty(a)gmail.com&gt; 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-... >>>> Sent from the Drools: User forum mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

On Nov 21, 2013, at 7:14 AM, Jonathan Knehr <jonathan.knehr(a)gmail.com&gt; wrote: 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 <dsotty(a)gmail.com&gt; 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 <dsotty(a)gmail.com&gt; 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 <dsotty(a)gmail.com&gt; 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-... >>>>>> Sent from the Drools: User forum mailing list archive at Nabble.com. >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> rules-users(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users

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-... > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list >

rules-users@.jboss

> _______________________________________________ rules-users mailing list

rules-users@.jboss

https://lists.jboss.org/mailman/listinfo/rules-users

That was recreated on 5.6.0.CR1 ? The 5.6 ship has sailed now :( and currently there are no plans for 5.7 any time soon. We should focus on making sure this is fixed in 6.x. Mark On 12 Jan 2014, at 19:21, nxv <nxvanderlinden(a)gmail.com <mailto:nxvanderlinden@gmail.com>> wrote: > Hello, > > I'm able to reproduce this issue with a KB containing only 1 rule. > > rule "Qualification##ToControl" > salience 50 > when > $p: AccessRegisterSnapshot( > $effDt: effectivedate ) > $dpo: DeliveryPoint() > $gCfg: GeneralConfig( > ( todate == null || > ( todate after[ 0d ] $effDt && > todate after[ 1ms ] fromdate ) ) ) > from $dpo.generalConfigs > then > > end > > This rule worked under drools 5.5.0.Final. > > Caused by: java.lang.NullPointerException at > org.drools.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluate(AfterEvaluatorDefinition.java:347) > at org.drools.base.EvaluatorWrapper.evaluate(EvaluatorWrapper.java:99) > > > > > Davide Sottara 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-... >>> Sent from the Drools: User forum mailing list archive at Nabble.com. >>> _______________________________________________ >>> rules-users mailing list >>> > >> rules-users@.jboss > >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> >> _______________________________________________ >> rules-users mailing list > >> rules-users@.jboss > >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > -- > View this message in > context: http://drools.46999.n3.nabble.com/5-6-0-CR1-gives-a-NullPointerException-... > Sent from the Drools: User forum mailing list archive at Nabble.com > <http://nabble.com/>;. > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

The problem is the same as reported by abr. I work with abr on the project :) As he could not reproduce the bug, I just removed lines of code as much as possible to keep only the essentials. Here is a unit test: Drools-after.zip <http://drools.46999.n3.nabble.com/file/n4027676/Drools-after.zip> Davide Sottara wrote > This is unlikely to be the same exception that started the initial > thread, but a problem nevertheless.. :( > could you create a self-contained test case and submit it? > Thanks > Davide > > On 01/13/2014 08:05 AM, Mark Proctor wrote: >> That was recreated on 5.6.0.CR1 ? The 5.6 ship has sailed now :( and >> currently there are no plans for 5.7 any time soon. We should focus on >> making sure this is fixed in 6.x. >> >> Mark >> On 12 Jan 2014, at 19:21, nxv &lt;

> nxvanderlinden@

> &gt; &lt;mailto:

> nxvanderlinden@

> &gt;> wrote: >> >>> Hello, >>> >>> I'm able to reproduce this issue with a KB containing only 1 rule. >>> >>> rule "Qualification##ToControl" >>> salience 50 >>> when >>> $p: AccessRegisterSnapshot( >>> $effDt: effectivedate ) >>> $dpo: DeliveryPoint() >>> $gCfg: GeneralConfig( >>> ( todate == null || >>> ( todate after[ 0d ] $effDt && >>> todate after[ 1ms ] fromdate ) ) ) >>> from $dpo.generalConfigs >>> then >>> >>> end >>> >>> This rule worked under drools 5.5.0.Final. >>> >>> Caused by: java.lang.NullPointerException at >>> org.drools.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluate(AfterEvaluatorDefinition.java:347) >>> at org.drools.base.EvaluatorWrapper.evaluate(EvaluatorWrapper.java:99) >>> >>> >>> >>> >>> Davide Sottara 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.