[jboss-jira] [JBoss JIRA] (DROOLS-156) Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations

[Davide Sottara (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778622#comment-12778622 ] 

Davide Sottara commented on DROOLS-156:
---------------------------------------

The internal memories for the Eval nodes are created "too lazily". 
In fact, if the eval node is not used, the memory will not be created at all, 
causing the exception when that memory has to be cleared during the rule
removal process.
It's a RETE construction bug, it will be fixed in 5.6+
                
> Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-156
>                 URL: https://issues.jboss.org/browse/DROOLS-156
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Philipp Herzig
>            Assignee: Mark Proctor
>         Attachments: EvalNodeDeletion.zip
>
>
> This bug is a little bit strange to explain. In some combinations the deletion of EvalConditionNodes gives an IndexOutOfBoundsException (see exception below). As consequence the rule is not correctly removed from the internal RETE representation leading to an inconsistent KnowledgeBase.
> I cannot dig it to the exact cause, but from my observation the exception comes from two factors: Number of eval nodes + an arbitrary number of other alpha and beta nodes. 
> I attached a dummy mvn project with senseless dummy rules that simulates the exception. The according JUnit is TestClass.java. With the class you can do the following tests:
> 1. Run it as is --> Exception at the primary removal point
> 2. Comment out the addition of "normalRule1" at line 111 --> Exception at the secondary removal point, i.e., one deletion works but adding and deleting again, raises exception
> 3. Comment out the addition of "normalRule2" --> No Exception.
> java.lang.IndexOutOfBoundsException: index 34
> 	at java.util.concurrent.atomic.AtomicReferenceArray.rawIndex(AtomicReferenceArray.java:31)
> 	at java.util.concurrent.atomic.AtomicReferenceArray.set(AtomicReferenceArray.java:94)
> 	at org.drools.common.ConcurrentNodeMemories.clearNodeMemory(ConcurrentNodeMemories.java:44)
> 	at org.drools.common.AbstractWorkingMemory.clearNodeMemory(AbstractWorkingMemory.java:1038)
> 	at org.drools.reteoo.EvalConditionNode.doRemove(EvalConditionNode.java:295)
> 	at org.drools.common.BaseNode.remove(BaseNode.java:115)
> 	at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:360)
> 	at org.drools.common.BaseNode.remove(BaseNode.java:115)
> 	at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:253)
> 	at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:459)
> 	at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1099)
> 	at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1077)
> 	at org.drools.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:207)
> 	at code.RuleEngine.deleteRule(RuleEngine.java:272)
> 	at test.TestClass.test(TestClass.java:122)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

--
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