I recently upgraded from 5.2.0 Final to 5.3.0 CR1 because I was experiencing memory leaks in 5.2.0 Final due to a known bug that was fixed in 5.3.0 CR1. I have a suite of FitNesse tests that exercise the majority of my rules and flows, and I can demonstrate that the memory leak is indeed fixed, but one of my tests is now failing. If I revert back to 5.2.0 Final, all is well. I've been trying to determine the root cause for the past 3 days, but I'm not getting anywhere. I suspect that it's related to an interaction between 2 rules, e.g. one rule modifies something that causes the second rule to fire, but the second rule chokes in the consequence when it tries to execute a modify() statement. If I comment out the modify portion, the rule fires fine. I wish I could provide an example, but my implementation is too complex for that and I haven't been able to reproduce it in a stand-alone example. I know a stack trace probably won't tell you much, but I've included it below just in case. If anyone has any ideas, I'd love to hear them. If there's any additional information you think might help diagnose the problem, I'd be happy to provide it. Thanks, Jamie org.drools.runtime.rule.ConsequenceException: rule: Rule 022 - Load Buyer Activity at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1101) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1029) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:708) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:672) at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218) at com.llbean.fraud.rule.engine.DroolsRulesEngine.invokeRules(DroolsRulesEngine.java:119) at com.llbean.fraud.rule.engine.DroolsRulesEngine.invokeRules(DroolsRulesEngine.java:81) at com.llbean.fraud.fitnesse.fixtures.tests.TestFraudRules.execute(TestFraudRules.java:116) at fit.ColumnFixture.executeIfNeeded(ColumnFixture.java:57) at fit.ColumnFixture.check(ColumnFixture.java:46) at fit.Binding$QueryBinding.doCell(Binding.java:188) at fit.ColumnFixture.doCell(ColumnFixture.java:37) at fit.Fixture.doCells(Fixture.java:171) at fit.Fixture.doRow(Fixture.java:165) at fit.ColumnFixture.doRow(ColumnFixture.java:25) at fit.Fixture.doRows(Fixture.java:159) at fit.ColumnFixture.doRows(ColumnFixture.java:18) at fit.Fixture.doTable(Fixture.java:153) at fit.Fixture.interpretFollowingTables(Fixture.java:119) at fit.Fixture.interpretTables(Fixture.java:105) at fit.Fixture.doTables(Fixture.java:79) at com.llbean.test.fitnesse.servletrunner.server.LLBFitServer.process(LLBFitServer.java:120) at com.llbean.test.fitnesse.servletrunner.server.LLBFitServer.runTests(LLBFitServer.java:40) at com.llbean.test.fitnesse.servletrunner.servlet.FitServlet.service(FitServlet.java:32) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1530) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:829) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:458) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:175) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:862) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:178) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:272) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550) Caused by: java.lang.NullPointerException at org.drools.reteoo.RuleTerminalNode.createActivations(RuleTerminalNode.java:276) at org.drools.reteoo.RuleTerminalNode.modifyLeftTuple(RuleTerminalNode.java:326) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(SingleLeftTupleSinkAdapter.java:273) at org.drools.reteoo.EvalConditionNode.modifyLeftTuple(EvalConditionNode.java:234) at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateModifyChildLeftTuple(CompositeLeftTupleSinkAdapter.java:295) at org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:380) at org.drools.reteoo.BetaNode.modifyLeftTuple(BetaNode.java:450) at org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:446) at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateModifyObject(CompositeLeftTupleSinkAdapter.java:260) at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateModifyObject(CompositeLeftTupleSinkAdapter.java:275) at org.drools.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:174) at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:461) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:429) at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:277) at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:271) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:459) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:363) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:298) at com.llbean.droolstest.Rule_Rule_022___Load_Buyer_Activity.defaultConsequence(Rule_Rule_022___Load_Buyer_Activity.java:15) at com.llbean.droolstest.Rule_Rule_022___Load_Buyer_ActivityDefaultConsequenceInvokerGenerated.evaluate(Unknown Source) at com.llbean.droolstest.Rule_Rule_022___Load_Buyer_ActivityDefaultConsequenceInvoker.evaluate(Unknown Source) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1091) ... 45 more -- View this message in context: http://drools.46999.n3.nabble.com/5-3-0-CR1-has-broken-existing-rules-flo... 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

This is very good info. I have found those Drools ConsequenceExceptions a real PITA to troubleshoot. I wonder if the exception could be enhanced to show this info so users don't have to debug it? I mean, to have the exception message show the true culprit rule name, or something useful like that? -- View this message in context: http://drools.46999.n3.nabble.com/5-3-0-CR1-has-broken-existing-rules-flo... 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

That looks really useful, I didn't know that you could do that! Any chance you could submit it as a patch to get the default version enhanced to do that!

Thanks, Thomas *From:*rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] *On Behalf Of *Wolfgang Laun *Sent:* 04 October 2011 08:42 *To:* Rules Users List *Subject:* Re: [rules-users] 5.3.0 CR1 has broken existing rules/flows I have found that any serious Drools application should write and deploy a consequence exception handler of its own. Perhaps you look at my modest effort <http://members.inode.at/w.laun/drools/CustomConsequenceExceptionHandlingH... - I think it is still compatible. Any feedback welcome ;-) -W On 4 October 2011 04:46, lhorton <LHorton(a)abclegal.com <mailto:LHorton@abclegal.com>> wrote: This is very good info. I have found those Drools ConsequenceExceptions a real PITA to troubleshoot. I wonder if the exception could be enhanced to show this info so users don't have to debug it? I mean, to have the exception message show the true culprit rule name, or something useful like that? -- View this message in context: http://drools.46999.n3.nabble.com/5-3-0-CR1-has-broken-existing-rules-flo... Sent from the Drools: User forum mailing list archive at 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 ------------------------------------------------------------------------ ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ************************************************************************************** _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Thanks for all of the feedback. I haven't tried W's handler, but I'm planning to. I did take Edson's advice and was able to get some more info. It appears to involve the interaction between 3 rules. For background, this is a fraud detection application. Under certain conditions, we need to look up additional customer information. Some rules are run to determine whether the lookup is required and then another rule actually does the lookup. In this case: Rule 021 says if the order is small, set the lookup flag to false Rule 042B says if the order is from a 'bad' country, set the lookup flag to true Rule 022 says if the lookup flag is true, do the lookup If rule 021 fires alone, then 022 does not fire and all is well. If rule 042B fires alone, then 022 fires and all is well. If 021 fires to turn off the lookup AND 042B fires to turn on the lookup, then 022 gets and NPE. As Edson suspected, the item is null and the 'rule' variable points to rule 021. I'm not sure if it matters, but each rules involved is in a different agenda group. As I mentioned, this works in 5.2.0.Final, but breaks in 5.3.0.CR1. Hope this helps pinpoint the issue. -- View this message in context: http://drools.46999.n3.nabble.com/5-3-0-CR1-has-broken-existing-rules-flo... 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