[JBoss JIRA] (DROOLS-1155) ClassCastException after deserialization of kiebase
by Mariano Nicolas De Maio (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1155?page=com.atlassian.jira.plugi... ]
Mariano Nicolas De Maio commented on DROOLS-1155:
-------------------------------------------------
Stack trace obtained after serialized kie base is deserialized, a KieSession is created, and used exactly the same way as before:
testSerializedKbase(org.drools.issue.test.RuleEngineTest) Time elapsed: 7.548 sec <<< ERROR!
java.lang.RuntimeException: inMonthDayInterval($evalTime, 9, 1, 4, 1) : java.lang.ClassCastException: org.drools.core.reteoo.InitialFactImpl cannot be cast to org.drools.issue.trait.EvalTime
at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:123)
at org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:70)
at org.drools.core.phreak.PhreakEvalNode.doNode(PhreakEvalNode.java:54)
at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:349)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1333)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1324)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1305)
at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:111)
at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36)
at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:136)
at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:220)
at org.drools.issue.test.RuleEngineTest.executeRules(RuleEngineTest.java:120)
at org.drools.issue.test.RuleEngineTest.testSerializedKbase(RuleEngineTest.java:93)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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.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.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.ClassCastException: org.drools.core.reteoo.InitialFactImpl cannot be cast to org.drools.issue.trait.EvalTime
at org.drools.base.org.drools.issue.trait.EvalTime1463823265$getEvalTime.getValue(Unknown Source)
at org.drools.core.base.ClassFieldReader.getValue(ClassFieldReader.java:91)
at org.drools.core.rule.Declaration.getValue(Declaration.java:214)
at org.drools.core.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:389)
at org.drools.core.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:333)
at org.drools.core.base.mvel.MVELEvalExpression.evaluate(MVELEvalExpression.java:88)
at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:118)
... 50 more
> ClassCastException after deserialization of kiebase
> ---------------------------------------------------
>
> Key: DROOLS-1155
> URL: https://issues.jboss.org/browse/DROOLS-1155
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 7.0.0.Beta1
> Reporter: Mariano Nicolas De Maio
> Assignee: Mario Fusco
> Attachments: issue-repro.tar.gz
>
>
> After the fix for issue DROOLS-1123, I was able to follow deserialize the kie base correctly. However, after deserialization, the kie sessions do not behave in the same way. The attached project has a reproduction case for the difference in behavior
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6666) clustering-web-infinispan: infinite recursion in session activation code
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6666?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-6666.
------------------------------
Resolution: Out of Date
The 9.x branch is no longer active.
> clustering-web-infinispan: infinite recursion in session activation code
> ------------------------------------------------------------------------
>
> Key: WFLY-6666
> URL: https://issues.jboss.org/browse/WFLY-6666
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.2.Final
> Reporter: Kamil Podlešák
> Assignee: Paul Ferraro
> Attachments: stacktrace, stacktrace2
>
>
> When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError.
> As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request, so it usually quite quickly disappears by log rotation.
> Version 10.0.0 is OK (the code is completely different and does not have this problem).
> See also: WFLY-6665 (similar, but not exactly the same bug).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1197) concurrency issue when having multiple kie containers
by Viacheslav Krot (JIRA)
Viacheslav Krot created DROOLS-1197:
---------------------------------------
Summary: concurrency issue when having multiple kie containers
Key: DROOLS-1197
URL: https://issues.jboss.org/browse/DROOLS-1197
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Viacheslav Krot
Assignee: Mario Fusco
It seems there is some bug related to concurrency when creating multiple kie containers in different threads.
Here is a test, that runs two threads, each has a loop creating a new kie container and running rule with stateless session. I expect this usecase to work, but it fails eventually - at some point in time kie container has loaded rules other than expected.
Is the test wrong or is there is a bug?
{{noformat}}
import static org.hamcrest.Matchers.hasSize;
import static org.junit.Assert.assertThat;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.concurrent.CompletableFuture;
import org.junit.Test;
import org.kie.api.KieServices;
import org.kie.api.builder.KieBuilder;
import org.kie.api.builder.KieFileSystem;
import org.kie.api.builder.Message;
import org.kie.api.io.KieResources;
import org.kie.api.io.Resource;
import org.kie.api.runtime.KieContainer;
public class ConcurrencyTest {
KieContainer createContainer(String rule) {
KieServices kieServices = KieServices.Factory.get();
KieResources kieResources = kieServices.getResources();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
Resource resource = kieResources.newByteArrayResource(rule.getBytes());
kieFileSystem.write("src/main/resources/rule.drl", resource);
KieBuilder kb = kieServices.newKieBuilder(kieFileSystem).buildAll();
if (kb.getResults().hasMessages(Message.Level.ERROR)) {
throw new RuntimeException("Build Errors:\n" + kb.getResults().toString());
}
return kieServices.newKieContainer(kb.getKieModule().getReleaseId());
}
String returns1 = "import java.util.List;\n" +
"\n" +
"rule \"rule1\"\n" +
"\tdialect \"mvel\"\n" +
"\twhen\n" +
"\t\tres : List( )\n" +
"\tthen\n" +
" res.add(\"1\");\n" +
"end";
String returns2 = "import java.util.List;\n" +
"\n" +
"rule \"rule1\"\n" +
"\tdialect \"mvel\"\n" +
"\twhen\n" +
"\t\tres : List( )\n" +
"\tthen\n" +
" res.add(\"1\");\n" +
" res.add(\"2\");\n" +
"end";
@Test
public void test() throws Exception {
CompletableFuture<?> f1 = CompletableFuture.runAsync(() -> {
for (int i = 0; i < 100; i++) {
List<String> res1 = new ArrayList<>();
createContainer(returns1).newStatelessKieSession().execute(Arrays.asList(res1));
assertThat(res1, hasSize(1));
}
});
CompletableFuture<?> f2 = CompletableFuture.runAsync(() -> {
for (int i = 0; i < 100; i++) {
List<String> res2 = new ArrayList<>();
createContainer(returns2).newStatelessKieSession().execute(Arrays.asList(res2));
assertThat(res2, hasSize(2));
}
});
f1.get();
f2.get();
}
}
{{noformat}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6666) clustering-web-infinispan: infinite recursion in session activation code
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6666?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-6666:
------------------------------------
Assignee: Paul Ferraro (was: Jason Greene)
> clustering-web-infinispan: infinite recursion in session activation code
> ------------------------------------------------------------------------
>
> Key: WFLY-6666
> URL: https://issues.jboss.org/browse/WFLY-6666
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final
> Reporter: Kamil Podlešák
> Assignee: Paul Ferraro
> Attachments: stacktrace, stacktrace2
>
>
> When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError.
> As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request, so it usually quite quickly disappears by log rotation.
> Version 10.0.0 is OK (the code is completely different and does not have this problem).
> See also: WFLY-6665 (similar, but not exactly the same bug).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6666) clustering-web-infinispan: infinite recursion in session activation code
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6666?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6666:
---------------------------------
Component/s: Clustering
> clustering-web-infinispan: infinite recursion in session activation code
> ------------------------------------------------------------------------
>
> Key: WFLY-6666
> URL: https://issues.jboss.org/browse/WFLY-6666
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.2.Final
> Reporter: Kamil Podlešák
> Assignee: Paul Ferraro
> Attachments: stacktrace, stacktrace2
>
>
> When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError.
> As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request, so it usually quite quickly disappears by log rotation.
> Version 10.0.0 is OK (the code is completely different and does not have this problem).
> See also: WFLY-6665 (similar, but not exactly the same bug).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6666) clustering-web-infinispan: infinite recursion in session activation code
by Kamil Podlešák (JIRA)
[ https://issues.jboss.org/browse/WFLY-6666?page=com.atlassian.jira.plugin.... ]
Kamil Podlešák commented on WFLY-6666:
--------------------------------------
Quick hotfix: https://github.com/podlesh/wildfly/tree/hotfix/inifinte-loop-detection
Tests, it *does* solve the problem - but it's too much of a hack for proper pull request (IMO).
> clustering-web-infinispan: infinite recursion in session activation code
> ------------------------------------------------------------------------
>
> Key: WFLY-6666
> URL: https://issues.jboss.org/browse/WFLY-6666
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final
> Reporter: Kamil Podlešák
> Assignee: Jason Greene
> Attachments: stacktrace, stacktrace2
>
>
> When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError.
> As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request, so it usually quite quickly disappears by log rotation.
> Version 10.0.0 is OK (the code is completely different and does not have this problem).
> See also: WFLY-6665 (similar, but not exactly the same bug).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6666) clustering-web-infinispan: infinite recursion in session activation code
by Kamil Podlešák (JIRA)
[ https://issues.jboss.org/browse/WFLY-6666?page=com.atlassian.jira.plugin.... ]
Kamil Podlešák updated WFLY-6666:
---------------------------------
Description:
When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError.
As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request, so it usually quite quickly disappears by log rotation.
Version 10.0.0 is OK (the code is completely different and does not have this problem).
See also: WFLY-6665 (similar, but not exactly the same bug).
was:
When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError.
As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request which means it usually quickly gets rolled away.
Version 10.0.0 is OK (the code is completely different and does not have this problem).
See also: WFLY-6665 (similar, but not exactly the same bug).
> clustering-web-infinispan: infinite recursion in session activation code
> ------------------------------------------------------------------------
>
> Key: WFLY-6666
> URL: https://issues.jboss.org/browse/WFLY-6666
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final
> Reporter: Kamil Podlešák
> Assignee: Jason Greene
> Attachments: stacktrace, stacktrace2
>
>
> When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError.
> As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request, so it usually quite quickly disappears by log rotation.
> Version 10.0.0 is OK (the code is completely different and does not have this problem).
> See also: WFLY-6665 (similar, but not exactly the same bug).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months