[jboss-jira] [JBoss JIRA] (DROOLS-333) PHREAK throws ClassCastException on rule with accumulate, temporal reasoning and conditional named consequence
Duncan Doyle (JIRA)
jira-events at lists.jboss.org
Sun Nov 10 14:43:05 EST 2013
Duncan Doyle created DROOLS-333:
-----------------------------------
Summary: PHREAK throws ClassCastException on rule with accumulate, temporal reasoning and conditional named consequence
Key: DROOLS-333
URL: https://issues.jboss.org/browse/DROOLS-333
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.CR5
Environment: Mac OS-X 10.9, Oracle Hotspot 1.7.0_45
Reporter: Duncan Doyle
Assignee: Mark Proctor
Reproducer at: https://github.com/DuncanDoyle/DroolsPhreakIssues
Clone the project in the given GitHub repository and run 'mvn -Pphreak clean test' (-Pphreak runs the test with PHREAK, -Preteoo runs the test with ReteOO).
Note that the 'testRG_FLT_03_Two' is intended to fail because, as you can see from the comments in the testcode and the .drl, the logic of the rule is actually wrong. However, it does force
the PHREAK engine to throw a ClassCastException every now and then. Note: not always (it might actually takes a number of test runs to reproduce the ClassCastException. It seems to depend on
how many events you enter into the system in one batch ....)!!
Sometimes 'testRG_FLT_03_Two' fails, with:
Failed tests: testRG_FLT_03_Two(org.jboss.ddoyle.drools.sample.PhreakyTest): Two last event must be in working memory expected:<12> but was:<1>
and sometimes it throws:
<error message="org.drools.core.reteoo.EvalNodeLeftTuple cannot be cast to org.drools.core.reteoo.RuleTerminalNodeLeftTuple" type="java.lang.ClassCastException">java.lang.ClassCastException: org.drools.core.reteoo.EvalNodeLeftTuple cannot be cast to org.drools.core.reteoo.RuleTerminalNodeLeftTuple
at org.drools.core.phreak.PhreakRuleTerminalNode.doLeftTupleUpdate(PhreakRuleTerminalNode.java:155)
at org.drools.core.phreak.PhreakBranchNode.doLeftUpdates(PhreakBranchNode.java:153)
at org.drools.core.phreak.PhreakBranchNode.doNode(PhreakBranchNode.java:31)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:364)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:199)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:66)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:927)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1187)
at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:931)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
at org.jboss.ddoyle.drools.sample.PhreakyTest.testFrequencyTwo(PhreakyTest.java:91)
at org.jboss.ddoyle.drools.sample.PhreakyTest.testRG_FLT_03_Two(PhreakyTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
</error>
The behaviour seems a bit random (which concerns me as well, as ReteOO was deterministic and would produce the same results on every test). Note that if I remove the
conditional named consequence construct and split the rule into 2 rules, the behaviour of PHREAK seems deterministic and I get this, expected, error (which is the same error I get with ReteOO):
Failed tests: testRG_FLT_03_Two(org.jboss.ddoyle.drools.sample.PhreakyTest): Two last event must be in working memory expected:<12> but was:<30>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list