[rules-users] Question about custom accumulation functions
Bruno Freudensprung
bruno.freudensprung at temis.com
Thu Sep 8 09:36:13 EDT 2011
I am using Drools 5.1.1.
Do you want me to package a small maven project exhibiting that error,
and post a Jira?
Bruno.
Le 08/09/2011 15:04, Edson Tirelli a écrit :
>
> It looks like a bug, as it should not raise a NPE no matter
> what.... which version of Drools are you using?
>
> Edson
>
> 2011/9/8 Bruno Freudensprung <bruno.freudensprung at temis.com
> <mailto:bruno.freudensprung at temis.com>>
>
>
> Hi Edson, hi all,
>
> To stick to the subject, I have a strange problem (stack trace in
> PS) with a rule containing two accumulate calls, the result of the
> first one is re-injected as the input of the second one. Those
> accumulate functions are "home made".
> The first one (tokenize) returns an ArrayList of Token objects
> built by tokenizing the "text" of the Sentence objects.
> The second one (build10windows) returns an ArrayList of Window
> objects, each one them containing 10 consecutive tokens.
> Here is the rule
>
> when
> $budget : ManualAnnotation(text == "something")
> *$tokens* : java.util.ArrayList() *from accumulate *($s :
> Sentence(), *tokenize*($s))
> $windows : java.util.ArrayList() *from accumulate *($t :
> Token() *from $tokens*, *build10windows*($t))
> # removed a part here but the problem occurs even without
> this part
> then
> retract($budget);
>
> Is there anything else one should be aware of when implementing
> their own accumulate function? I mean things related to the fact
> that "classical" accumulate functions (sum, average) return an
> immutable object that does not share anything with the context object.
> Although accumulate, reverse, and getResult methods of my
> functions are unit tested, I suspect something that could be
> related to stateless/stateful considerations.
> What do you think?
>
> Many thanks,
>
> Bruno.
>
> PS :
>
> The stack trace is:
> at
> org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> at
> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:927)
> 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)
> at
> org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:99)
> at
> org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:33)
> at
> org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:159)
> at
> org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:81)
> at
> org.drools.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:262)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at
> org.drools.reteoo.AccumulateNode.getFirstMatch(AccumulateNode.java:967)
> at
> org.drools.reteoo.AccumulateNode.splitList(AccumulateNode.java:920)
> at
> org.drools.reteoo.AccumulateNode.removePreviousMatchesForLeftTuple(AccumulateNode.java:874)
> at
> org.drools.reteoo.AccumulateNode.retractLeftTuple(AccumulateNode.java:205)
> at
> org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateRetractLeftTuple(CompositeLeftTupleSinkAdapter.java:238)
> at
> org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateRetractLeftTupleDestroyRightTuple(CompositeLeftTupleSinkAdapter.java:138)
> at
> org.drools.reteoo.AccumulateNode.retractLeftTuple(AccumulateNode.java:212)
> at
> org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:240)
> at
> org.drools.reteoo.EntryPointNode.retractObject(EntryPointNode.java:231)
> at
> org.drools.common.AbstractWorkingMemory.retract(AbstractWorkingMemory.java:1288)
> at
> org.drools.base.DefaultKnowledgeHelper.retract(DefaultKnowledgeHelper.java:201)
> at
> org.drools.base.DefaultKnowledgeHelper.retract(DefaultKnowledgeHelper.java:214)
> at
> defaultpkg.Rule_Display_windows_0.defaultConsequence(Rule_Display_windows_0.java:21)
> at
> defaultpkg.Rule_Display_windows_0DefaultConsequenceInvoker.evaluate(Rule_Display_windows_0DefaultConsequenceInvoker.java:29)
> at
> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:917)
> ... 15 more
>
>
>
> Bruno.
>
> Le 24/08/2011 16:21, Edson Tirelli a écrit :
>>
>> Yes, evaluation is incremental, so for every new fact, it will
>> call accumulate() and getResult().
>>
>> We do want to reduce the calls to getResult(), improving
>> performance, but it is not easy to figure out a way, as from an
>> engine perspective, it never knows when the application is done
>> inserting facts and it is time to calculate the final result.
>>
>> Edson
>>
>> 2011/8/24 Bruno Freudensprung <bruno.freudensprung at temis.com
>> <mailto:bruno.freudensprung at temis.com>>
>>
>> Hi,
>>
>> While testing my custom accumulation function I noticed an
>> unexpected
>> behavior (th'ats of course a personal point of view).
>> It seems that Drools 5.1 calls accumulate(...) and
>> getResult(...) as
>> many times as the number of accumulated facts (accumulate,
>> getResult,
>> accumulate, getResult, etc...).
>> Is it supposed to work like this?
>>
>> Best regards,
>>
>> Bruno.
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto: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 <http://www.jboss.com>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org <mailto: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 <http://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/20110908/f8d81578/attachment.html
More information about the rules-users
mailing list