Thanks a lot, and I've added your analysis as a comment to JBRULES-2887. Wolfgang 2011/4/3 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; > Hi Wolfgang: > > I write to you concerning JIRA > https://issues.jboss.org/browse/JBRULES-2887, which the SampleAlarmRules > scenario which was attached to this discussion was added in. > > I've executed several times the SampleAlarmRules scenario and found that > the problem in that scenario is the existence of a JoinNode (Node 18) which > feeds two nodes, a JoinNode (Node 20) and an AccumlateNode (Node 25, the one > in which NPE occurs). I've seen that the child tuples of a join node are > interconnected via pointers and that those connections must be updated every > time a parent tuple of the join node is modified, via reAddLeft and > reAddRight tuple methods. When a JoinNode feeds two or more nodes, the child > tuples are interconnected in a ordered way that mixes tuples with different > sinks. > > In the SampleAlarmRules scenario, when JoinNode18 is right modified, the > CompositeLeftTupleSinkAdapter processes several child tuples, but only the > last one is returned and reAddLeft'ed, hence breaking the child tuple > relations which it seems necessary to keep rete coherence. After this right > modify, the next left modify fails because a child tuple related to one node > of the composite sink is used to check the next operation to do in another > sink node different from the first one. This leads to a chain of incorrect > assertions which ends in the AccumulateNode NPE. > > I've rewriten my rules in order to JoinNode18 feeds only AccumulateNode25 > thus avoiding the NPE and returning to my user role. However I am not sure > if any CompositeSink starting at a JoinNode will have this or other problems > when being left or right modified. I hope this information helps to solve > this problem. > > Best regards, > > Manuel Ortiz. > > > 2011/3/31 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; > >> >> >> 2011/3/31 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >> >>> Hi Wofgang: >>> >>> Thank youvery much for your response. I was replaying to Mauricio when >>> your email has arrived. I hope the test case is useful. >>> >>> >> Thanks. Files are attached to the JIRA and JIRA is now at "critical". >> -W >> >> >>> Best regards, >>> >>> Manuel Ortiz. >>> >>> >>> 2011/3/31 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; >>> >>>> Manuel, >>>> >>>> I have reported this (or a very similar) problem >>>> https://issues.jboss.org/browse/JBRULES-2887 with a small example to >>>> reproduce. >>>> >>>> The stack trace is not identical, so please try to reproduce this with >>>> a small test case; it is bound to happen with a rule (Test Negativo Alarma >>>> Acceso Portal Ubicacion UM) that modifies some fact that is used in an >>>> "accumulate" phrase, (If this pattern is different from the one I gave, I'll >>>> raise the issue priority to "critical".) >>>> >>>> Cheers >>>> Wolfgang >>>> >>>> >>>> 2011/3/30 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >>>> >>>>> Hello all! >>>>> >>>>> I am new in Drools but day by day, test by test, I think I get a bit >>>>> more knowledge of how the rule engine works from user point of view. I've >>>>> been adding rules to an alarm system, increasing the complexity and >>>>> functionality in several steps. Unfortunately in the last step I found the >>>>> following NullPointerException inside the rule engine... >>>>> >>>>> java.lang.NullPointerException >>>>> at >>>>> org.drools.reteoo.AccumulateNode.getFirstMatch(AccumulateNode.java:967) >>>>> at >>>>> org.drools.reteoo.AccumulateNode.modifyLeftTuple(AccumulateNode.java:329) >>>>> at >>>>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(SingleLeftTupleSinkAdapter.java:239) >>>>> at >>>>> org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:640) >>>>> at >>>>> org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:270) >>>>> at org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:312) >>>>> at >>>>> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:460) >>>>> at >>>>> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:428) >>>>> at org.drools.reteoo.AlphaNode.modifyObject(AlphaNode.java:160) >>>>> at >>>>> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:460) >>>>> at >>>>> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:428) >>>>> at >>>>> org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:263) >>>>> at >>>>> org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:172) >>>>> at >>>>> org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1442) >>>>> at >>>>> org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1349) >>>>> at >>>>> org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:183) >>>>> at >>>>> org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:196) >>>>> at >>>>> es.simcasva.alarmas.rules.Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0.defaultConsequence(Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0.java:18) >>>>> at >>>>> es.simcasva.alarmas.rules.Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0DefaultConsequenceInvoker.evaluate(Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0DefaultConsequenceInvoker.java:44) >>>>> at >>>>> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:917) >>>>> at >>>>> org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:856) >>>>> at >>>>> org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1071) >>>>> at >>>>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:785) >>>>> at >>>>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:751) >>>>> at >>>>> org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218) >>>>> >>>>> I've been trying to find the problem, and found a strange interaction >>>>> between three rules that makes the null pointer to appear. The alarm system >>>>> has many rules now and it is difficult to simplify the scenario, so I just >>>>> would like to know what is the funcion of AccumulateNode object in order to >>>>> have an idea of the NullPointerException possible cause. >>>>> >>>>> Can anyone help me? >>>>> >>>>> Thank you in advance for your time. >>>>> >>>>> Regards, >>>>> >>>>> Manuel Ortiz. >>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Manuel, Thanks for your detailed analysis. I believe this was fixed in trunk a few weeks ago. Edson 2011/4/3 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; > Hi again: > > I've been thinking about a possible solution to the SampleAlarmRules > scenario related problem and would suggest that every sink modify function > which returns a child tuple to be reAddLeft'ed or reAddRight'ed (at least > there is one which is LeftTupleSinkPropagator.propagateModifyChildLeftTuple) > returns an array of tuples instead of only one tuple, to take into account > that the sink can be a composite sink which processes several child tuples, > and reAddLeft or reAddRight all the tuples of the array to maintain tuple > connection coherence. > > Best regards, > > Manuel Ortiz. > > > > 2011/4/3 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; > >> Thanks a lot, and I've added your analysis as a comment to JBRULES-2887. >> Wolfgang >> >> >> 2011/4/3 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >> >>> Hi Wolfgang: >>> >>> I write to you concerning JIRA >>> https://issues.jboss.org/browse/JBRULES-2887, which the >>> SampleAlarmRules scenario which was attached to this discussion was added >>> in. >>> >>> I've executed several times the SampleAlarmRules scenario and found that >>> the problem in that scenario is the existence of a JoinNode (Node 18) which >>> feeds two nodes, a JoinNode (Node 20) and an AccumlateNode (Node 25, the one >>> in which NPE occurs). I've seen that the child tuples of a join node are >>> interconnected via pointers and that those connections must be updated every >>> time a parent tuple of the join node is modified, via reAddLeft and >>> reAddRight tuple methods. When a JoinNode feeds two or more nodes, the child >>> tuples are interconnected in a ordered way that mixes tuples with different >>> sinks. >>> >>> In the SampleAlarmRules scenario, when JoinNode18 is right modified, the >>> CompositeLeftTupleSinkAdapter processes several child tuples, but only the >>> last one is returned and reAddLeft'ed, hence breaking the child tuple >>> relations which it seems necessary to keep rete coherence. After this right >>> modify, the next left modify fails because a child tuple related to one node >>> of the composite sink is used to check the next operation to do in another >>> sink node different from the first one. This leads to a chain of incorrect >>> assertions which ends in the AccumulateNode NPE. >>> >>> I've rewriten my rules in order to JoinNode18 feeds only >>> AccumulateNode25 thus avoiding the NPE and returning to my user role. >>> However I am not sure if any CompositeSink starting at a JoinNode will have >>> this or other problems when being left or right modified. I hope this >>> information helps to solve this problem. >>> >>> Best regards, >>> >>> Manuel Ortiz. >>> >>> >>> 2011/3/31 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; >>> >>>> >>>> >>>> 2011/3/31 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >>>> >>>>> Hi Wofgang: >>>>> >>>>> Thank youvery much for your response. I was replaying to Mauricio when >>>>> your email has arrived. I hope the test case is useful. >>>>> >>>>> >>>> Thanks. Files are attached to the JIRA and JIRA is now at "critical". >>>> -W >>>> >>>> >>>>> Best regards, >>>>> >>>>> Manuel Ortiz. >>>>> >>>>> >>>>> 2011/3/31 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; >>>>> >>>>>> Manuel, >>>>>> >>>>>> I have reported this (or a very similar) problem >>>>>> https://issues.jboss.org/browse/JBRULES-2887 with a small example >>>>>> to reproduce. >>>>>> >>>>>> The stack trace is not identical, so please try to reproduce this >>>>>> with a small test case; it is bound to happen with a rule (Test Negativo >>>>>> Alarma Acceso Portal Ubicacion UM) that modifies some fact that is used in >>>>>> an "accumulate" phrase, (If this pattern is different from the one I gave, >>>>>> I'll raise the issue priority to "critical".) >>>>>> >>>>>> Cheers >>>>>> Wolfgang >>>>>> >>>>>> >>>>>> 2011/3/30 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >>>>>> >>>>>>> Hello all! >>>>>>> >>>>>>> I am new in Drools but day by day, test by test, I think I get a bit >>>>>>> more knowledge of how the rule engine works from user point of view. I've >>>>>>> been adding rules to an alarm system, increasing the complexity and >>>>>>> functionality in several steps. Unfortunately in the last step I found the >>>>>>> following NullPointerException inside the rule engine... >>>>>>> >>>>>>> java.lang.NullPointerException >>>>>>> at >>>>>>> org.drools.reteoo.AccumulateNode.getFirstMatch(AccumulateNode.java:967) >>>>>>> at >>>>>>> org.drools.reteoo.AccumulateNode.modifyLeftTuple(AccumulateNode.java:329) >>>>>>> at >>>>>>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(SingleLeftTupleSinkAdapter.java:239) >>>>>>> at >>>>>>> org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:640) >>>>>>> at >>>>>>> org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:270) >>>>>>> at org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:312) >>>>>>> at >>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:460) >>>>>>> at >>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:428) >>>>>>> at org.drools.reteoo.AlphaNode.modifyObject(AlphaNode.java:160) >>>>>>> at >>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:460) >>>>>>> at >>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:428) >>>>>>> at >>>>>>> org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:263) >>>>>>> at >>>>>>> org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:172) >>>>>>> at >>>>>>> org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1442) >>>>>>> at >>>>>>> org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1349) >>>>>>> at >>>>>>> org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:183) >>>>>>> at >>>>>>> org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:196) >>>>>>> at >>>>>>> es.simcasva.alarmas.rules.Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0.defaultConsequence(Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0.java:18) >>>>>>> at >>>>>>> es.simcasva.alarmas.rules.Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0DefaultConsequenceInvoker.evaluate(Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0DefaultConsequenceInvoker.java:44) >>>>>>> at >>>>>>> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:917) >>>>>>> at >>>>>>> org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:856) >>>>>>> at >>>>>>> org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1071) >>>>>>> at >>>>>>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:785) >>>>>>> at >>>>>>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:751) >>>>>>> at >>>>>>> org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218) >>>>>>> >>>>>>> I've been trying to find the problem, and found a strange >>>>>>> interaction between three rules that makes the null pointer to appear. The >>>>>>> alarm system has many rules now and it is difficult to simplify the >>>>>>> scenario, so I just would like to know what is the funcion of AccumulateNode >>>>>>> object in order to have an idea of the NullPointerException possible cause. >>>>>>> >>>>>>> Can anyone help me? >>>>>>> >>>>>>> Thank you in advance for your time. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Manuel Ortiz. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> rules-users(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> rules-users(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Hi again: Just to inform I've made slight modifications to JoinNode code locally that seems to solve the SampleAlarmRules problem and any other problem (up to now) in my application rule set related to JoinNodes whose sink is composite. If anyone needs these modifications while the corrected release version comes up, just tell me. Best regards, Manuel Ortiz. 2011/4/4 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; > Hi Edson, Wolfgang: > > Is there a downloadable Drools Release, beta or whatever, in which this > problem is fixed? I think it may be the cause of some other problems I'm > suffering (sometimes, some restrictions in the Condition Element seems to be > badly evaluated and I think this may arise from bad tuple connections too). > I would like to discard this possible cause before diving in Drools > code again. > > Thank you for your time. > > Kind regards, > > Manuel Ortiz. > > > 2011/4/4 Edson Tirelli <ed.tirelli(a)gmail.com&gt; > >> >> Manuel, >> >> Thanks for your detailed analysis. I believe this was fixed in trunk a >> few weeks ago. >> >> Edson >> >> >> 2011/4/3 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >> >>> Hi again: >>> >>> I've been thinking about a possible solution to the SampleAlarmRules >>> scenario related problem and would suggest that every sink modify function >>> which returns a child tuple to be reAddLeft'ed or reAddRight'ed (at least >>> there is one which is LeftTupleSinkPropagator.propagateModifyChildLeftTuple) >>> returns an array of tuples instead of only one tuple, to take into account >>> that the sink can be a composite sink which processes several child tuples, >>> and reAddLeft or reAddRight all the tuples of the array to maintain tuple >>> connection coherence. >>> >>> Best regards, >>> >>> Manuel Ortiz. >>> >>> >>> >>> 2011/4/3 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; >>> >>>> Thanks a lot, and I've added your analysis as a comment to >>>> JBRULES-2887. >>>> Wolfgang >>>> >>>> >>>> 2011/4/3 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >>>> >>>>> Hi Wolfgang: >>>>> >>>>> I write to you concerning JIRA >>>>> https://issues.jboss.org/browse/JBRULES-2887, which the >>>>> SampleAlarmRules scenario which was attached to this discussion was added >>>>> in. >>>>> >>>>> I've executed several times the SampleAlarmRules scenario and found >>>>> that the problem in that scenario is the existence of a JoinNode (Node 18) >>>>> which feeds two nodes, a JoinNode (Node 20) and an AccumlateNode (Node 25, >>>>> the one in which NPE occurs). I've seen that the child tuples of a join node >>>>> are interconnected via pointers and that those connections must be updated >>>>> every time a parent tuple of the join node is modified, via reAddLeft and >>>>> reAddRight tuple methods. When a JoinNode feeds two or more nodes, the child >>>>> tuples are interconnected in a ordered way that mixes tuples with different >>>>> sinks. >>>>> >>>>> In the SampleAlarmRules scenario, when JoinNode18 is right modified, >>>>> the CompositeLeftTupleSinkAdapter processes several child tuples, but only >>>>> the last one is returned and reAddLeft'ed, hence breaking the child tuple >>>>> relations which it seems necessary to keep rete coherence. After this right >>>>> modify, the next left modify fails because a child tuple related to one node >>>>> of the composite sink is used to check the next operation to do in another >>>>> sink node different from the first one. This leads to a chain of incorrect >>>>> assertions which ends in the AccumulateNode NPE. >>>>> >>>>> I've rewriten my rules in order to JoinNode18 feeds only >>>>> AccumulateNode25 thus avoiding the NPE and returning to my user role. >>>>> However I am not sure if any CompositeSink starting at a JoinNode will have >>>>> this or other problems when being left or right modified. I hope this >>>>> information helps to solve this problem. >>>>> >>>>> Best regards, >>>>> >>>>> Manuel Ortiz. >>>>> >>>>> >>>>> 2011/3/31 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; >>>>> >>>>>> >>>>>> >>>>>> 2011/3/31 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >>>>>> >>>>>>> Hi Wofgang: >>>>>>> >>>>>>> Thank youvery much for your response. I was replaying to Mauricio >>>>>>> when your email has arrived. I hope the test case is useful. >>>>>>> >>>>>>> >>>>>> Thanks. Files are attached to the JIRA and JIRA is now at "critical". >>>>>> -W >>>>>> >>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Manuel Ortiz. >>>>>>> >>>>>>> >>>>>>> 2011/3/31 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; >>>>>>> >>>>>>>> Manuel, >>>>>>>> >>>>>>>> I have reported this (or a very similar) problem >>>>>>>> https://issues.jboss.org/browse/JBRULES-2887 with a small example >>>>>>>> to reproduce. >>>>>>>> >>>>>>>> The stack trace is not identical, so please try to reproduce this >>>>>>>> with a small test case; it is bound to happen with a rule (Test Negativo >>>>>>>> Alarma Acceso Portal Ubicacion UM) that modifies some fact that is used in >>>>>>>> an "accumulate" phrase, (If this pattern is different from the one I gave, >>>>>>>> I'll raise the issue priority to "critical".) >>>>>>>> >>>>>>>> Cheers >>>>>>>> Wolfgang >>>>>>>> >>>>>>>> >>>>>>>> 2011/3/30 Manuel Ortiz <manuel.ortizramos(a)gmail.com&gt; >>>>>>>> >>>>>>>>> Hello all! >>>>>>>>> >>>>>>>>> I am new in Drools but day by day, test by test, I think I get a >>>>>>>>> bit more knowledge of how the rule engine works from user point of view. >>>>>>>>> I've been adding rules to an alarm system, increasing the complexity and >>>>>>>>> functionality in several steps. Unfortunately in the last step I found the >>>>>>>>> following NullPointerException inside the rule engine... >>>>>>>>> >>>>>>>>> java.lang.NullPointerException >>>>>>>>> at >>>>>>>>> org.drools.reteoo.AccumulateNode.getFirstMatch(AccumulateNode.java:967) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.AccumulateNode.modifyLeftTuple(AccumulateNode.java:329) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(SingleLeftTupleSinkAdapter.java:239) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:640) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:270) >>>>>>>>> at org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:312) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:460) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:428) >>>>>>>>> at org.drools.reteoo.AlphaNode.modifyObject(AlphaNode.java:160) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:460) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:428) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:263) >>>>>>>>> at >>>>>>>>> org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:172) >>>>>>>>> at >>>>>>>>> org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1442) >>>>>>>>> at >>>>>>>>> org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1349) >>>>>>>>> at >>>>>>>>> org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:183) >>>>>>>>> at >>>>>>>>> org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:196) >>>>>>>>> at >>>>>>>>> es.simcasva.alarmas.rules.Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0.defaultConsequence(Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0.java:18) >>>>>>>>> at >>>>>>>>> es.simcasva.alarmas.rules.Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0DefaultConsequenceInvoker.evaluate(Rule_Test_Negativo_Alarma_Acceso_Portal_Ubicacion_UM_0DefaultConsequenceInvoker.java:44) >>>>>>>>> at >>>>>>>>> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:917) >>>>>>>>> at >>>>>>>>> org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:856) >>>>>>>>> at >>>>>>>>> org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1071) >>>>>>>>> at >>>>>>>>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:785) >>>>>>>>> at >>>>>>>>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:751) >>>>>>>>> at >>>>>>>>> org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218) >>>>>>>>> >>>>>>>>> I've been trying to find the problem, and found a strange >>>>>>>>> interaction between three rules that makes the null pointer to appear. The >>>>>>>>> alarm system has many rules now and it is difficult to simplify the >>>>>>>>> scenario, so I just would like to know what is the funcion of AccumulateNode >>>>>>>>> object in order to have an idea of the NullPointerException possible cause. >>>>>>>>> >>>>>>>>> Can anyone help me? >>>>>>>>> >>>>>>>>> Thank you in advance for your time. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Manuel Ortiz. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> rules-users mailing list >>>>>>>>> rules-users(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> rules-users mailing list >>>>>>>> rules-users(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> rules-users(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> rules-users(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> >> -- >> Edson Tirelli >> JBoss Drools Core Development >> JBoss by Red Hat @ www.jboss.com >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users