Re: [rules-users] Manuel's Analysis of JBRULES-2887 (NPE in AccumulateNode.java:967)

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 > >