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>
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>
> 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>
>
>> 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>
>>
>>> 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>
>>>
>>>>
>>>>
>>>> 2011/3/31 Manuel Ortiz <manuel.ortizramos(a)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(a)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(a)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(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