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

Mon Apr 4 08:39:46 EDT 2011

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

>
>    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 at gmail.com>
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at 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 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/0eb8ab25/attachment.html 