[jboss-jira] [JBoss JIRA] Updated: (JBRULES-2098) Internal TupleSink list is not properly cleaned up when removing rules from a RuleBase
Christian Nedregård (JIRA)
jira-events at lists.jboss.org
Mon May 25 08:36:56 EDT 2009
[ https://jira.jboss.org/jira/browse/JBRULES-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Nedregård updated JBRULES-2098:
------------------------------------------
Description:
When a new rule is added to a rule base that has shareBetaNodes=true 'BuildUtils.attachNode' will iterate through existing TupleSink nodes and try to find an equal node to re-use.
In our production code we are seing NoClassDefFoundErrors from 'EvalConditionNode.equals' in scenarios where rules are both removed from and added to a rule base. The NoClassDefFoundErrors occours when a rule has recently been removed from the rule base and we are trying to add a new rule. When BuildUtils.attachNode' iterates through the existing TupleSinks it also encounters TupleSinks that belongs to the rule that was removed. The call to the TupleSinks 'equal' method yields a NoClassDefFoundErrors because the target TupleSink are trying to reference the rule class that has been removed.
In this scenario we have removed rule 10418 and are adding 11140:
java.lang.NoClassDefFoundError: rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0
at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.class$(Unknown Source)
at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.getMethodBytecode(Unknown Source)
at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_11140_0Eval0Invoker.equals(Unknown Source)
at org.drools.rule.EvalCondition.equals(EvalCondition.java:121)
at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101)
Attached is a stand-alone JUnit 3 testcase where the test 'testWithBetaNodeSharing' shows this problem. It does not produce a NoClassDefFoundError but we get a NPE from <removed rule>Eval0Invoker.getMethodBytecode instead (rule 1 has been removed, rule 3 is about to be added):
java.lang.NullPointerException
at failure_on_removal.Rule_rule_1_0Eval0Invoker.getMethodBytecode(Unknown Source)
at failure_on_removal.Rule_rule_3_0Eval0Invoker.equals(Unknown Source)
at org.drools.rule.EvalCondition.equals(EvalCondition.java:121)
at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101)
We intepret this to be a symptom of the same problem.
The workaround is to disable beta node sharing wich will bypass the TupleSink iteration alltogheter. This is shown in the test 'testWithoutBetaNodeSharing'.
Kind regards
Christian Nedregård
was:
When a new rule is added to a rule base that has shareBetaNodes=true 'BuildUtils.attachNode' will iterate through existing TupleSink nodes and try to find an equal node to re-use.
In our production code we are seing NoClassDefFoundErrors from 'EvalConditionNode.equals' in scenarios where rules are both removed from and added to a rule base. The NoClassDefFoundErrors occours when a rule has recently been removed from the rule base and we are trying to add a new rule. When BuildUtils.attachNode' iterates through the existing TupleSinks it also encounters TupleSinks that belongs to the rule that was removed. The call to the TupleSinks 'equal' method yields a NoClassDefFoundErrors because the target TupleSink are trying to reference the rule class that has been removed.
In this scenario we have removed rule 10418 and are adding 11140:
java.lang.NoClassDefFoundError: rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0
at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.class$(Unknown Source)
at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.getMethodBytecode(Unknown Source)
at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_11140_0Eval0Invoker.equals(Unknown Source)
at org.drools.rule.EvalCondition.equals(EvalCondition.java:121)
at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101)
Attached is a stand-alone JUnit 4 testcase where the test 'testWithBetaNodeSharing' shows this problem. It does not produce a NoClassDefFoundError but we get a NPE from <removed rule>Eval0Invoker.getMethodBytecode instead (rule 1 has been removed, rule 3 is about to be added):
java.lang.NullPointerException
at failure_on_removal.Rule_rule_1_0Eval0Invoker.getMethodBytecode(Unknown Source)
at failure_on_removal.Rule_rule_3_0Eval0Invoker.equals(Unknown Source)
at org.drools.rule.EvalCondition.equals(EvalCondition.java:121)
at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101)
We intepret this to be a symptom of the same problem.
The workaround is to disable beta node sharing wich will bypass the TupleSink iteration alltogheter. This is shown in the test 'testWithoutBetaNodeSharing'.
Kind regards
Christian Nedregård
> Internal TupleSink list is not properly cleaned up when removing rules from a RuleBase
> --------------------------------------------------------------------------------------
>
> Key: JBRULES-2098
> URL: https://jira.jboss.org/jira/browse/JBRULES-2098
> Project: JBoss Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 4.0.7
> Environment: Drools 4.0.7
> Win XP
> Sun JDK 1.4.2_11
> Reporter: Christian Nedregård
> Assignee: Mark Proctor
> Attachments: FailureOnRemovalTest.java
>
>
> When a new rule is added to a rule base that has shareBetaNodes=true 'BuildUtils.attachNode' will iterate through existing TupleSink nodes and try to find an equal node to re-use.
> In our production code we are seing NoClassDefFoundErrors from 'EvalConditionNode.equals' in scenarios where rules are both removed from and added to a rule base. The NoClassDefFoundErrors occours when a rule has recently been removed from the rule base and we are trying to add a new rule. When BuildUtils.attachNode' iterates through the existing TupleSinks it also encounters TupleSinks that belongs to the rule that was removed. The call to the TupleSinks 'equal' method yields a NoClassDefFoundErrors because the target TupleSink are trying to reference the rule class that has been removed.
> In this scenario we have removed rule 10418 and are adding 11140:
> java.lang.NoClassDefFoundError: rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0
> at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.class$(Unknown Source)
> at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.getMethodBytecode(Unknown Source)
> at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_11140_0Eval0Invoker.equals(Unknown Source)
> at org.drools.rule.EvalCondition.equals(EvalCondition.java:121)
> at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201)
> at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101)
> Attached is a stand-alone JUnit 3 testcase where the test 'testWithBetaNodeSharing' shows this problem. It does not produce a NoClassDefFoundError but we get a NPE from <removed rule>Eval0Invoker.getMethodBytecode instead (rule 1 has been removed, rule 3 is about to be added):
> java.lang.NullPointerException
> at failure_on_removal.Rule_rule_1_0Eval0Invoker.getMethodBytecode(Unknown Source)
> at failure_on_removal.Rule_rule_3_0Eval0Invoker.equals(Unknown Source)
> at org.drools.rule.EvalCondition.equals(EvalCondition.java:121)
> at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201)
> at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101)
> We intepret this to be a symptom of the same problem.
> The workaround is to disable beta node sharing wich will bypass the TupleSink iteration alltogheter. This is shown in the test 'testWithoutBetaNodeSharing'.
> Kind regards
> Christian Nedregård
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list