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

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