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

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: Mark Proctor 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