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

Davide Sottara dsotty at gmail.com
Thu Dec 12 19:18:00 EST 2013


Could you please try version 5.6.CR1 ? It's not available for download
on the main
web site, but maven will be able to retrieve it.
It has many fixes, including some multi threading issues. If you still
experience the problem,
we'll try and find a way to fix it in 5.6.Final, or test it with 6.x
Thanks
Davide

On 12/12/2013 07:34 AM, Anders Henriksson wrote:
> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20131212/8fdbf887/attachment.html 


More information about the rules-users mailing list