[jboss-jira] [JBoss JIRA] (JBRULES-3285) NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance)

[Geoffrey De Smet (JIRA)]

     [ https://issues.jboss.org/browse/JBRULES-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated JBRULES-3285:
--------------------------------------

    Fix Version/s: 5.4.0.Beta3
                       (was: 5.4.0.Beta2)

    
> NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3285
>                 URL: https://issues.jboss.org/browse/JBRULES-3285
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.3.0.Final
>            Reporter: Richard Calmbach
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 5.4.0.Beta3
>
>
> See the forum reference above for context. As requested, this is the bug report for issue F2 in the post. The intro and description are copied from the original post:
> I am making extensive use of the event processing features of the Drools rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke 47 of my unit tests and also broke my functional tests. There seem to be multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break backward compatibility. Here are the results of my investigation so far.
> Issue F2:
> This is the bug that causes my unit tests to fail. I have not pinpointed the root cause, but it seems to have to do with the event scheduling Drools does as part of its job execution mechanism. Its symptom is a NullPointerException during insertion of an event. What makes it so tricky is that with the out-of-the-box configuration, Drools catches such exceptions in org.drools.time.impl.PseudoClockScheduler.runCallBacks() and passes them to the aptly named "DoNothingSystemEventListener", which literally does nothing, not so much as logging (the methods are empty). So you don't actually know that the event insertion failed, you only wonder why your mock WorkingMemoryEventListener is telling you that your expectations are not met. The stack trace (as copied from the Eclipse Debug view, hence the unusual formatting) inside Drools is:
> Date.getMillisOf(Date) line: 939
> Date.compareTo(Date) line: 959
> DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) line: 38
> DefaultTimerJobInstance.compareTo(Object) line: 13
> PriorityQueue<E>.siftUpComparable(int, E) line: 582
> PriorityQueue<E>.siftUp(int, E) line: 574
> PriorityQueue<E>.offer(E) line: 274
> PriorityQueue<E>.add(E) line: 251
> PseudoClockScheduler.internalSchedule(TimerJobInstance) line: 136
> PseudoClockScheduler.scheduleJob(Job, JobContext, Trigger) line: 126
> ObjectTypeNode.assertObject(InternalFactHandle, PropagationContext, InternalWorkingMemory) line: 230
> EntryPointNode.assertObject(InternalFactHandle, PropagationContext, ObjectTypeConf, InternalWorkingMemory) line: 244
> NamedEntryPoint.insert(InternalFactHandle, Object, Rule, Activation, ObjectTypeConf) line: 330
> NamedEntryPoint.insert(Object, boolean, boolean, Rule, Activation) line: 291
> NamedEntryPoint.insert(Object) line: 116
> NamedEntryPoint.insert(Object) line: 48
> <my code calling into Drools>
> Here is method org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance):
> {code}
>     public int compareTo(DefaultTimerJobInstance o) {
>         return this.trigger.hasNextFireTime().compareTo( o.getTrigger().hasNextFireTime() );
>     }    
> {code}
> Essentially, this method calls java.util.Date.compareTo(Date) with a null argument, which, as documented, causes a NullPointerException. Sometimes, this.trigger.hasNextFireTime() already returns null, and then the NPE gets thrown in DefaultTimerJobInstance.compareTo() itself.
> I've seen different stack traces leading to this NPE, so this must be affecting scheduling and job execution quite broadly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira