| Summary: | A rule condition is not performed when a fact is updated | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] JBoss BPMS Platform 6 | Reporter: | Ivo Bek <ibek> | ||||
| Component: | jBPM Core | Assignee: | Maciej Swiderski <mswiders> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ivo Bek <ibek> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 6.0.0 | CC: | kverlaen | ||||
| Target Milestone: | ER5 | ||||||
| Target Release: | 6.0.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-08-06 20:13:23 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: | |||||
| Attachments: |
|
||||||
|
Description
Ivo Bek
2013-10-09 09:13:52 UTC
Ivo, are you also inserting the process instance itself into the ksession after starting it? yes, sure I add the process instance too. Here is the whole java code http://pastebin.com/78GUmkDi I was too hurry, the issue is with the first process http://pastebin.com/YnGmLSKY the behavior has changed in the way how rules are activated. In v6 drools uses lazy activation and thus fireAllRules must be invoked to trigger the evaluation. In comparison to v5 where activation happened on insert/update/retract. That means that whenever conditional events are used fireAllRules must be used to properly trigger rules after facts were inserted/update/retracted. So I believe this is not a bug but expected behavior which requires most likely documentation update that rule engine uses lazy activation and requires fireAllRules to be invoked. Maciej, rules could also be defined as @eager (see for example https://github.com/droolsjbpm/jbpm/blob/master/jbpm-flow-builder/src/main/java/org/jbpm/compiler/ProcessBuilderImpl.java#L408) to avoid this. It seems most of the generated rules use this, although gateway constraints and start event constraints don't seem to have that annotation yet. So I believe adding that annotation there as well would make sense and solve this issue. Kris, I am aware of this but unfortunately it does not mean the rule will be activated on insert/update/retract basis and thus fireAllRules is still mandatory to get that working. I double checked that with drools team and the @Eager places rules only on top of the processing queue. There are some discussion on how that might be supported on drools side but currently there is no way to activate the rule without fireAllRules. Based on modifications applied on drools side now we can configure ksession to activate rules that are marked as @Eager on insert/update/retract basis. Configuration by default is done for RuntimeManager: config.setOption(ForceEagerActivationOption.YES); where config is KieSessionConfiguration jbpm master: https://github.com/droolsjbpm/jbpm/commit/b1c09c26c03d6e0523beb4abf40dbd8e7efa2250 https://github.com/droolsjbpm/jbpm/commit/f644b7565f7f28f7d68fc6ec11a28ae6863be58a 6.0.x https://github.com/droolsjbpm/jbpm/commit/0720077005125d8d141210197869864dbcbfe322 https://github.com/droolsjbpm/jbpm/commit/5c580eeca837758541124972d735c0b20d6b4fef Verified in BPMS 6.0.0.ER5. Seems, ForceEagerActivationOption is set by default because I didn't have to change anything. I just removed the fireAllRules method for the test with rules condition. |