Bug 1040889 - NullPointerException on JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is modified
Summary: NullPointerException on JPAKnowledgeService.loadStatefulKnowledgeSession() wh...
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: BRE
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER 7
: 6.0.0
Assignee: Mario Fusco
QA Contact: Tomas Schlosser
Depends On:
Blocks: 1040891 1080504
TreeView+ depends on / blocked
Reported: 2013-12-12 09:38 UTC by Toshiya Kobayashi
Modified: 2018-12-03 20:55 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1040891 (view as bug list)
Last Closed: 2014-08-06 20:16:07 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker DROOLS-376 0 Major Resolved NullPointerException on JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is modified 2014-08-14 03:00:18 UTC

Description Toshiya Kobayashi 2013-12-12 09:38:09 UTC
Description of problem:

Platform BZ for https://issues.jboss.org/browse/DROOLS-376

Steps to Reproduce:

Please see DROOLS-376

Actual results:


Expected results:

Able to load ksession

Comment 1 Edson Tirelli 2013-12-12 16:04:50 UTC
This is a customer case request. Requires fixing in 5.3.1 as well.


Comment 2 Mario Fusco 2013-12-13 10:56:13 UTC
Fixed by https://github.com/droolsjbpm/drools/commit/384b22588

Comment 3 Edson Tirelli 2013-12-13 15:51:46 UTC

Mario fixed the NPE in the engine as it should not raise a NPE no matter what, but looking at the sample test case provided, it is clear that the NPE is a symptom of a problem with the rule itself:

rule rule1
 $p: Person($list : addresses)
 $a: Address(street == "y") from $list
 $list.add( new Address("z") );
 $list.add( new Address("w") );

The problem with the above rule is that the consequence of the rule modifies the Person object (by adding addresses), but does not notify the engine about doing that.

It might look ok, but the working memory is stale after the execution of the rule because the engine does not know the person object changed. After serializing this stale working memory, when deserializing, the engine notices that the person object changed, and it will try to cope with the change as best as possible, but the net result for the customer application is that the deserialized session (up to date) will be different from the serialized one (stale). This will probably cause bugs in the customer application that will be hard to track down.

Please advise the customer to always call modify/update to notify the engine when a fact is changed. The above rule would require an additional constraint to prevent looping, but it is the right thing to do. There are several ways of doing that, e.g. using additional constraint:

rule rule1
 $p: Person($list : addresses)
 $a: Address(street == "y") from $list
 not( Address( street == "z" ) from $list )
 $list.add( new Address("z") );
 $list.add( new Address("w") );
 update( $p );

It might be possible to use property reactive feature, or no-loop, or lock-on-active instead.

Comment 6 Tomas Schlosser 2014-01-15 08:50:06 UTC
Verified with BRMS 6.0.1-redhat-2

Note You need to log in before you can comment on or make changes to this bug.