Re: [rules-users] Null pointer when inserting data (5.5.0.Final)

Hi! We're running drools in a multi-server setup, with a pretty basic scenario: 1. When the first session is needed, we load the rulebase once. The rulebase is never changed after this (no rule removal or addition). 2. Each call spawns a new StatefulKnowledgeSession which is used for firing the rules once and then disposed. These calls are heavily multi-threaded, but each session is only used in a single method call from a single thread. 3. We use the resource scanner to check for updated packages. When an updated knowledge package is available, the knowledgebase is discarded and a new one constructed from the updated package. The knowledge package affected is somewhat large - about 25 MB in size. (There are other, smaller knowledge packages which do not appear to have this issue.) This setup has been working fine, but somewhat slow. After upgrading to 5.5.0.Final and adding some speedups in the surrounding code we get a spurious null pointer. The trail of events is: 1. After start all servers work fine. 2. Sometime after a couple of hours to a couple of days, the null pointer error occurs on one or more servers (but generally not all of them). 3. Once the null pointer occurs, it happens on all further calls using that knowledgebase. No other knowledgebases are effected. (You can load the same package in a new knowledgebase, and sessions using the new, identical, knowledgebase work just fine.) 4. Restarting the java process makes the server work fine again. Calls always fail with the same stack trace: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction@5db53f 24 at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:995) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:335) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269) <stacktrace from our calling code omitted> Caused by: java.lang.NullPointerException at org.drools.rule.EvalCondition.createContext(EvalCondition.java:107) at org.drools.reteoo.EvalConditionNode.createMemory(EvalConditionNode.java:261) at org.drools.common.ConcurrentNodeMemories.createNodeMemory(ConcurrentNodeMemories.java:90) at org.drools.common.ConcurrentNodeMemories.getNodeMemory(ConcurrentNodeMemories.java:69) at org.drools.common.AbstractWorkingMemory.getNodeMemory(AbstractWorkingMemory.java:1034) at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:174) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196) at org.drools.reteoo.SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:145) at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) at org.drools.reteoo.Rete.assertObject(Rete.java:109) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:286) at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:434) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:993) ... 93 more Unfortunately we don't have the remaining rows in the wrapped exception. From this trace, it looks like the problem is in EvalCondition: public Object createContext() { return this.expression.createContext(); } which should only be able to produce a null pointer if expression is missing. Looking at the constructors for this class, having a null expression seems like a valid use case - but if this is a valid use case, why doesn't createContext() handle this case? Considering that running drools with the same package and the same inputs can either fail with the above error (if knowledgebase has been used enough) or work just as intended (using a newly minted knowledgebase), it feels like something is corrupting the knowledgebase. Does this make sense? (I noticed in the issue tracker ( https://issues.jboss.org/browse/DROOLS-156 ) that memory for eval nodes are 'created "too lazily"' - might this be a related issue?) Best regards, Anders _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users