January 2012 - jboss-jira - Jboss List Archives

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

by Richard Calmbach (Created) (JIRA)

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

13 years, 6 months

6
7
0 / 0

[JBoss JIRA] Created: (JBRULES-3228) Method for inserting facts via entryPoints from a DRL is not documented

by Michael Pellegrini (JIRA)

Method for inserting facts via entryPoints from a DRL is not documented ------------------------------------------------------------------------ Key: JBRULES-3228 URL: https://issues.jboss.org/browse/JBRULES-3228 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-docs Affects Versions: 5.3.0.CR1 Reporter: Michael Pellegrini Assignee: Mark Proctor The current documentation does not describe how to insert fact into a specific entryPoint from with the DRL. Either using the drools object reference or the shortcut version. rule "test" when then entryPoint["name"].insert() end -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
10
0 / 0

[JBoss JIRA] (JBRULES-3346) Batch execution code has not been finished and is missing tests

by Marco Rietveld (JIRA)

Marco Rietveld created JBRULES-3346: --------------------------------------- Summary: Batch execution code has not been finished and is missing tests Key: JBRULES-3346 URL: https://issues.jboss.org/browse/JBRULES-3346 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 5.4.0.Beta1 Reporter: Marco Rietveld Assignee: Marco Rietveld Priority: Minor Fix For: 5.3.2.Final, 5.4.0.Beta2 See [here|https://github.com/droolsjbpm/drools/blob/622d359886bf687a8397214f16...] for an example. -- 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

13 years, 6 months

4
5
0 / 0

[JBoss JIRA] (JBRULES-3334) AbstractTabuAcceptor doesn't add the starting solution as tabu

by Patrik Dufresne (Created) (JIRA)

AbstractTabuAcceptor doesn't add the starting solution as tabu -------------------------------------------------------------- Key: JBRULES-3334 URL: https://issues.jboss.org/browse/JBRULES-3334 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.3.1.Final Reporter: Patrik Dufresne Assignee: Mark Proctor When setting a complete solution tabu, the starting solution is not considered a Tabu making it possible to visit the same solution again. Consider a situation where there is construction phase followed by a local search phase. The construction phase will create a solution that will not be added to the tabu list of the local search phased. To fix it, I suggest to override the function phaseStarted(...) in SolutionTabuAcceptor to add solution to the Tabu map. -- 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

13 years, 6 months

9
10
0 / 0

[JBoss JIRA] (JBRULES-3324) Refactor the Simulation Fluents for World Remoting

by Mark Proctor (Created) (JIRA)

Refactor the Simulation Fluents for World Remoting -------------------------------------------------- Key: JBRULES-3324 URL: https://issues.jboss.org/browse/JBRULES-3324 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor -- 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

13 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2616) Process persistent timers

by Diego Lopez Leon (JIRA)

Process persistent timers ------------------------- Key: JBRULES-2616 URL: https://jira.jboss.org/browse/JBRULES-2616 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-process Affects Versions: 5.1.0.FINAL Reporter: Diego Lopez Leon Assignee: Mark Proctor Implement a mechanism to allow scheduled timers to be triggered beyond the scope of a disposed session. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (AS7-1459) Add a commandline flag to the startup script to enable debugging

by Dan Allen (JIRA)

Add a commandline flag to the startup script to enable debugging ---------------------------------------------------------------- Key: AS7-1459 URL: https://issues.jboss.org/browse/AS7-1459 Project: Application Server 7 Issue Type: Feature Request Components: CLI Affects Versions: 7.0.0.Final Reporter: Dan Allen Assignee: Alexey Loubyansky The startup script (standalone.sh & standalone.bat) should honor a commandline option that can be used to start the server with debugging enabled. Currently, the developer has to uncomment the JAVA_OPTS line in the standalone.conf file manually. Proposal for starting the server with debugging enabled: ./bin/standalone.sh --debug If necessary, the optional flag could accept the port as an optional argument. ./bin/standalone.sh --debug 8787 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
9
0 / 0

[JBoss JIRA] Created: (AS7-1133) MSC service in war file is loaded from WEB-INF/classes/META-INF/services instead of META-INF/services

by David Bosschaert (JIRA)

MSC service in war file is loaded from WEB-INF/classes/META-INF/services instead of META-INF/services ----------------------------------------------------------------------------------------------------- Key: AS7-1133 URL: https://issues.jboss.org/browse/AS7-1133 Project: Application Server 7 Issue Type: Bug Components: MSC, Web Affects Versions: 7.0.0.CR1 Reporter: David Bosschaert Priority: Minor When deploying a .war file that contains a META-INF/service/org.jboss.msc.service.ServiceActivator this file is only processed when it's in the WEB-INF/classes/META-INF/services location, where I think it should really be picked up fro /META-INF/services -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-8824) Cardinality constraints on children are not enforced after parsing

by Brian Stansberry (JIRA)

Cardinality constraints on children are not enforced after parsing ------------------------------------------------------------------ Key: JBAS-8824 URL: https://issues.jboss.org/browse/JBAS-8824 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Priority: Critical Fix For: 7.0.0.Beta1 The parsers enforce cardinality constraints on child elements in the model, but they aren't enforced thereafter. So, for example, a second "profile" or "socket-binding-group" could be added to a standalone server via a management operation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-1317) STABLE: compress STABLE messages

by Bela Ban (JIRA)

STABLE: compress STABLE messages -------------------------------- Key: JGRP-1317 URL: https://issues.jboss.org/browse/JGRP-1317 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.2, 3.1 For large clusters, stable messages are quite large, and should be compressed. E.g.: - Don't send the entire view (with all members), but only the ViewId, then the indices of a digest array would point to the rank of a member within the referred-to ViewId - A digest has 3 longs (low, highest_received and highest_delivered). Do we need all 3 every time ? - Compress the 3 longs into 1 long and 2 shorts: the latter 2 are offsets from the first seqno - Use a bit set (consisting of a variable number of ints) to set the 3 variables - If we have a digest (0), 0, 0: send a special marker - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect ! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
7
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2012