Bug 1040889
Summary: | NullPointerException on JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is modified | |||
---|---|---|---|---|
Product: | [Retired] JBoss BRMS Platform 6 | Reporter: | Toshiya Kobayashi <tkobayas> | |
Component: | BRE | Assignee: | Mario Fusco <mfusco> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Tomas Schlosser <tschloss> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 6.0.0 | CC: | 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
This is a customer case request. Requires fixing in 5.3.1 as well. https://bugzilla.redhat.com/show_bug.cgi?id=1040891 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. Verified with BRMS 6.0.1-redhat-2 |