Re: [rules-users] Question about custom accumulation functions
No way of guessing what code you have there. Why not start a new thread, with all the trimmings? (Code, version,...) -W On 25/10/2013, mikerod mjr4...@gmail.com wrote: On a somewhat related note: I have a rule, where the value of #getResult may match the constraint at some point during the accumulation, but later on will result in a value that does not match the constraint anymore. So in my scenario, the LHS of the rule is true at some point during the accumulation of working memory elements, so the RHS fires. My RHS logically inserts new facts into working memory, via #insertLogical. Later, the #getResult returns a non-matching value, and the LHS of the rule becomes false. However, from what I'm seeing, the facts inserted into working memory from intermediate matches of the LHS, are not being retracted when the LHS becomes false later on. Is this expected behavior? -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Question-about-custom-accumulation-functions-tp3280838p4026504.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Question about custom accumulation functions
I started the question in a new thread @ http://drools.46999.n3.nabble.com/Unexpected-behavior-of-accumulate-and-insertLogical-when-the-result-goes-from-matching-a-constraint-g-tp4026507.html -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Question-about-custom-accumulation-functions-tp3280838p4026508.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Question about custom accumulation functions
On a somewhat related note: I have a rule, where the value of #getResult may match the constraint at some point during the accumulation, but later on will result in a value that does not match the constraint anymore. So in my scenario, the LHS of the rule is true at some point during the accumulation of working memory elements, so the RHS fires. My RHS logically inserts new facts into working memory, via #insertLogical. Later, the #getResult returns a non-matching value, and the LHS of the rule becomes false. However, from what I'm seeing, the facts inserted into working memory from intermediate matches of the LHS, are not being retracted when the LHS becomes false later on. Is this expected behavior? -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Question-about-custom-accumulation-functions-tp3280838p4026504.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Question about custom accumulation functions
Hi Edson, Good news: the problem does not happen, neither with the 5.2.0.Final nor with the latest snapshot. Best regards, Bruno. Le 08/09/2011 17:17, Edson Tirelli a écrit : Bruno, Can you please test it with latest snapshot? If it is still a problem, then please open a JIRA and provide the test to reproduce it... https://hudson.jboss.org/jenkins/view/Drools%20jBPM/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/ Thanks, Edson ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Question about custom accumulation functions
Good. Thanks for letting us know. Edson 2011/9/14 Bruno Freudensprung bruno.freudenspr...@temis.com Hi Edson, Good news: the problem does not happen, neither with the 5.2.0.Final nor with the latest snapshot. Best regards, Bruno. Le 08/09/2011 17:17, Edson Tirelli a écrit : Bruno, Can you please test it with latest snapshot? If it is still a problem, then please open a JIRA and provide the test to reproduce it... https://hudson.jboss.org/jenkins/view/Drools%20jBPM/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/ Thanks, Edson ___ rules-users mailing list rules-users@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Question about custom accumulation functions
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.freudenspr...@temis.com mailto:bruno.freudenspr...@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.
Re: [rules-users] Question about custom accumulation functions
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.freudenspr...@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.freudenspr...@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
Re: [rules-users] Question about custom accumulation functions
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.freudenspr...@temis.com mailto:bruno.freudenspr...@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(),
Re: [rules-users] Question about custom accumulation functions
Bruno, Can you please test it with latest snapshot? If it is still a problem, then please open a JIRA and provide the test to reproduce it... https://hudson.jboss.org/jenkins/view/Drools%20jBPM/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/ Thanks, Edson 2011/9/8 Bruno Freudensprung bruno.freudenspr...@temis.com ** 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.freudenspr...@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
[rules-users] Question about custom accumulation functions
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
