[JBoss JIRA] (WFLY-410) Implement custom Stack resource for JGroups to maintain protocol order
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-410?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on WFLY-410:
------------------------------------------
Need some help with this one.
I started the implementation of a custom StackResource which holds the protocol order as a List<String> of protocol names. This variable is accessed by StackResource.getProtocols() and is updated each time we call registerChild(address, resource)/removeChild(address).
Everything was fine until I started looking at the marshalling code. In JGroupsSubsystemXmlWriter, I need to be able to access the StackResource in order to pick up the ordered list via StackResource.getProtocols(), but there is no OperationContext to work with. There must be a root resource which I can navigate from to get to the StackResource using Resource.navigate(resource, address), but i'm not sure which resource to start from, and whether this depends on the mode i'm in (standalone or domain). Any ideas?
Also, Resource.getChildren() returns a set and not a list. I only really need the protocol order for constructing the JGroups stack at runtime - but unless I use something like OrderedSets and a Comparator, when reading the resource, the user will see a list of protocol=X children which are not necessarily in the correct order. Not 100% sure that this is worth trying to set up, as there is otherwise stated no guarantee that protocol children will appear ordered. In this sense, having a read-only variable called protocols which shows the order is marginally better. WDYT?
> Implement custom Stack resource for JGroups to maintain protocol order
> -----------------------------------------------------------------------
>
> Key: WFLY-410
> URL: https://issues.jboss.org/browse/WFLY-410
> Project: WildFly
> Issue Type: Task
> Components: Clustering, Domain Management
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 8.0.0.Beta1
>
>
> A JGroups stack is a transport together with an ordered list of protocols. The transport and the protocols are maintained as child resources. There is no direct way to maintain the order of a set of protocol child resources, so we need to implement a custom resource which does this.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-1431) org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-1431?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-1431:
-------------------------------------
Chao, could you create a PR and EAP bugzilla for this please?
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1431
> URL: https://issues.jboss.org/browse/WFLY-1431
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Attachments: WFLY-1431.patch
>
>
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed with
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase.testInterceptorPostConstructWithProceed(InterceptorLifecycleSFSBTestCase.java:67)
> 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:601)
> 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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> 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.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {noformat}
--
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
10 years, 11 months
[JBoss JIRA] (DROOLS-156) Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
by Philipp Herzig (JIRA)
[ https://issues.jboss.org/browse/DROOLS-156?page=com.atlassian.jira.plugin... ]
Philipp Herzig updated DROOLS-156:
----------------------------------
Description:
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)
was:
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 removel point, i.e., one deletion works but adding a 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)
> 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
10 years, 11 months
[JBoss JIRA] (DROOLS-156) Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
by Philipp Herzig (JIRA)
[ https://issues.jboss.org/browse/DROOLS-156?page=com.atlassian.jira.plugin... ]
Philipp Herzig updated DROOLS-156:
----------------------------------
Description:
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 removel point, i.e., one deletion works but adding a 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)
was:
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 coorectly 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 test 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 removel point, i.e., one deletion works but adding a 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)
> 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 removel point, i.e., one deletion works but adding a 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
10 years, 11 months
[JBoss JIRA] (DROOLS-156) Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
by Philipp Herzig (JIRA)
Philipp Herzig created DROOLS-156:
-------------------------------------
Summary: 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 coorectly 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 test 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 removel point, i.e., one deletion works but adding a 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
10 years, 11 months