Bug 1040889

Summary: NullPointerException on JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is modified
Product: [Retired] JBoss BRMS Platform 6 Reporter: Toshiya Kobayashi <tkobayas>
Component: BREAssignee: Mario Fusco <mfusco>
Status: CLOSED CURRENTRELEASE QA Contact: Tomas Schlosser <tschloss>
Severity: high Docs Contact:
Priority: high    
Version: 6.0.0CC: etirelli, kverlaen, rrajasek, rzhang
Target Milestone: ER 7   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1040891 (view as bug list) Environment:
Last Closed: 2014-08-06 20:16:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1040891, 1080504    

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:

NullPointerException

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.

https://bugzilla.redhat.com/show_bug.cgi?id=1040891

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
Toshiya,

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
when
 $p: Person($list : addresses)
 $a: Address(street == "y") from $list
then
 $list.add( new Address("z") );
 $list.add( new Address("w") );
end

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
when
 $p: Person($list : addresses)
 $a: Address(street == "y") from $list
 not( Address( street == "z" ) from $list )
then
 $list.add( new Address("z") );
 $list.add( new Address("w") );
 update( $p );
end

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