Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations

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)