[jboss-jira] [JBoss JIRA] (DROOLS-1059) Drools can't find rules under stress

[ https://issues.jboss.org/browse/DROOLS-1059?page=com.atlassian.jira.plugi... ] Sebastian Schaer commented on DROOLS-1059: ------------------------------------------ Hi, I'm experiencing the same issue as well under a stress test situation: Seemingly random failures for queries (but they all exist). We typically run only about 10-20 rules though. I will try to add more information or work on a reproducer (if I find the time). Just my observations and an example stacktrace of the error we encounter: {code} INFO | jvm 1 | main | 2016/03/25 18:34:14.387 |  java.lang.RuntimeException: Unable to find query 'rule_2f6dc65eb814487eb37acde7c99c2a16_query' INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.getQueryLiaNode(SegmentUtilities.java:518) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:208) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.reteoo.SegmentMemory$QueryMemoryPrototype.populateMemory(SegmentMemory.java:505) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.reteoo.SegmentMemory$Prototype.newSegmentMemory(SegmentMemory.java:400) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.impl.KnowledgeBaseImpl.createSegmentFromPrototype(KnowledgeBaseImpl.java:1424) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.restoreSegmentFromPrototype(SegmentUtilities.java:186) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:83) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SegmentUtilities.createChildSegment(SegmentUtilities.java:321) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SegmentUtilities.createChildSegments(SegmentUtilities.java:313) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:186) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:170) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1270) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:107) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:153) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:69) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292) ~[drools-core-6.3.0.Final.jar:6.3.0.Final] {code} Unlike [~massinissa] we use stateless sessions and the exception happens when we execute the FireAllRulesCommand. I also implemented a very simple retry logic (limited to 5 retries) around this specific exception (catching this exception, and reusing the existing stateless session to execute the same command again) and so far I have not encountered any case where the exception gets thrown a second time. And from all I can tell the second time the FireAllRulesCommand is executed, the rule evaluation seems ok (we create/insert facts and all of that seems to be working fine). (So my preliminary workaround is to just re-execute the same command on the same session and it seems ok so far. This of course might not work with stateful sessions). -- This message was sent by Atlassian JIRA (v6.4.11#64026)