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

Sun Apr 3 18:32:30 EDT 2011

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 at gmail.com>

> Thanks a lot, and I've added your analysis as a comment to JBRULES-2887.
> Wolfgang
>
>
> 2011/4/3 Manuel Ortiz <manuel.ortizramos at gmail.com>
>
>> 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 at gmail.com>
>>
>>>
>>>
>>> 2011/3/31 Manuel Ortiz <manuel.ortizramos at gmail.com>
>>>
>>>> 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 at gmail.com>
>>>>
>>>>> 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 at gmail.com>
>>>>>
>>>>>> 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> rules-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110404/97856915/attachment.html 