Robert Crawford wrote: The exception may happen during working memory operations (e.g., an insert), so there isn't even a rule active. Which version of Drools are you using? In my case, switching from Drools 5.2.0.Final to Drools 5.3.0.Final broke 47 of my unit tests (1 error and 46 failures). The one that now gives an error, shows this stacktrace (similar to yours): org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.PropagationQueuingNode$PropagateAction@7a9b777a at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:977) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:315) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845) at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255) at com.acme.das.fraud.RulesTestBase.sendEot(RulesTestBase.java:139) at com.acme.das.fraud.RulesTestBase.advanceTime(RulesTestBase.java:131) at com.acme.das.fraud.RulesTestBase.advanceTime(RulesTestBase.java:135) at com.acme.das.fraud.RulesTest.testUdrAndThenStartCdrWithinTimeout(RulesTest.java:1061) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66) at org.jmock.integration.junit4.JMock$1.invoke(JMock.java:37) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:98) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:61) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:54) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.NullPointerException at java.util.PriorityQueue.siftUpComparable(PriorityQueue.java:582) at java.util.PriorityQueue.siftUp(PriorityQueue.java:574) at java.util.PriorityQueue.removeAt(PriorityQueue.java:550) at java.util.PriorityQueue.remove(PriorityQueue.java:309) at org.drools.time.impl.PseudoClockScheduler.removeJob(PseudoClockScheduler.java:147) at org.drools.common.Scheduler.removeAgendaItem(Scheduler.java:74) at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:543) at org.drools.common.ScheduledAgendaItem.remove(ScheduledAgendaItem.java:91) at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:385) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:225) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:99) at org.drools.reteoo.NotNode.propagateRetractLeftTuple(NotNode.java:453) at org.drools.reteoo.NotNode.assertObject(NotNode.java:148) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) at org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:354) at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:238) at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:502) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:975) ... 32 more Also, upgrading to Drools 5.3.0.Final is breaking my functional tests, too (real-time clock!). It's difficult to narrow down just what broke in Drools 5.3.0, but there seems to be a theme having to do with the session clock and timer service. In the unit tests, it seems none of the events after the first one get inserted. I'm using an event feeder based on the Fusion Broker example. If you haven't already, try running your code with Drools 5.2.0, just to get another data point. I have definitely seen incorrect behavior when having multiple threads insert events concurrently. Under certain limited conditions, it may be possible to run multithreaded inserts on the same session, but in the general case this is not guaranteed to work (empirically established). If your processing can be split into completely independent event streams, you can process each stream in its own knowledge session (in its own thread, hence giving you parallelism), but within each stream (or among a set of correlated streams, say events from one client), inserts need to be serialized by synchronizing on the session, otherwise you can get incorrect behavior (I know I did!). In a nutshell: Rule consequences are not executed atomically. -- View this message in context: http://drools.46999.n3.nabble.com/Help-with-troubleshooting-rules-Drools-... Sent from the Drools: User forum mailing list archive at Nabble.com.

I've rolled back to 5.2.0 and it seems to be doing better. Almost an hour of uptime. I already have a custom consequence exception handler -- I think it's cribbed from that link, even. But this exception doesn't appear to happen during the execution of a consequence -- I *think* it's during an event expiration, but I can't swear to that. -- View this message in context: http://drools.46999.n3.nabble.com/Help-with-troubleshooting-rules-Drools-... Sent from the Drools: User forum mailing list archive at Nabble.com.

On 1 November 2011 17:57, Robert Crawford <crawford(a)kloognome.com&gt; wrote: Sounds like it. Make sure to return false if rhe acc function cannot recompute the value with one of the contributors gone. -W