| Summary: | Timer start event does not emit start events repeatedly (in jBPM Console) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Jiri Locker <jlocker> | ||||
| Component: | jBPM Console | Assignee: | Kris Verlaenen <kverlaen> | ||||
| Status: | VERIFIED --- | QA Contact: | Marek Baluch <mbaluch> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | BRMS 5.3.0.GA | CC: | atangrin, lpetrovi, mfusco | ||||
| Target Milestone: | ER6 | ||||||
| Target Release: | BRMS 5.3.0.GA | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Incorrect serialization caused lost timers, which meant start events with a cycle time defined only started the first time, and all subsequent starts were lost. This has been resolved by fixing serialization so that timers are properly stored. Start events with a cycle time interval defined now work as expected.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 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: |
|
||||||
Created attachment 568349 [details]
TimerProcess.bpmn2
*** Bug 811986 has been marked as a duplicate of this bug. *** This issue affects any timer node (not only start event timer). That's why I filed the duplicate issue. Timer rule is now activated on startup of session. In general, rules will automatically be fired when they are activated in the jbpm console from now on. Update status to ON_QA. Please verify them against ER6. The process itself is not started by jBPM console (but that is already reported as Bug 813183). When process is added pulled from Guvnor, it is not started and when I order the test to be started manually, it starts right away and does not trigger more than once. The problem might be absence of fireAllRules() method call. As I understood, it is called when the session is created. However the process is added later and fireAllRules() is not called again. Spent some time on this issue to reproduce it and here are my findings: tested on both BRMS 5.3.0 GA and latest master (5.4.0-SHNAPSHOT) but behaviour is inconsistent: BRMS 5.3.0 GA (EAP 5) attached process is invoked only once regardless if session is created or loaded from data base Master (JBoss AS 7.0.2) attached process executes properly on new session but on loaded from data base it is not activated and fired - adding session.insert(summyFact) makes it work properly currently working on a test case for this, will update as soon as have one. First of all please ignore previous comment about inconsistency, this inconsistency was caused by BRMS was configured to fetch processes from guvnor while master fetched them from file ssytem. After more digging into the issue it turns out to be composed of two problems: - it happens only when knowledge base is built based on binary package - in case of console it is fetched from guvnor - after restart/reload of the session it can fail (with NPE) on JPAWorkingMemoryDbLogger due to overdue timers being executed before JPAWorkingMemoryDbLogger is completely initialized First problem seems to be fixed on master but could not locate what fixed it as both tests [1] complete successfully. Second problem could be done in two ways: - make changes only to JPAWorkingMemoryDbLogger/WorkingMemoryLogger to let initialize itself before registering event listeners - deleay execution of overdue timers to allow registration of event listners/work item handlers before timer is fired Here is a test case that illustrates the issue, can be easily merged into both master and 5.2.x: https://github.com/droolsjbpm/jbpm/pull/120 fix applied for drools code base, commit https://github.com/droolsjbpm/drools/commit/00396f335393ff523528a892d63c82b74bd1a34c It solves the first part of the issue and the other is available as part of following bz https://bugzilla.redhat.com/show_bug.cgi?id=820309 to have fully functional repeatable timers both must be applied merged into master and 5.2.x Edson fixed the timer serialization with this commit: https://github.com/droolsjbpm/drools/commit/00396f335393ff523528a892d63c82b74bd1a34c That fix uncovered 2 further bugs that caused the failure of 2 unit tests: - TimerAndCalendarTest.testTimerWithNot fixed by cancelling the job handle related with a cancelled activation - TimerAndCalendarTest.testHaltWithTimer fixed by checking if the agenda has been halted both those 2 fixes have been pushed with this commit: https://github.com/droolsjbpm/drools/commit/aed459f00c863c3582af1d2daf9a24abbbd55f2d based on discussion on IRC all timer bugs are fixed Verified in BRMS 5.3.1 ER1. Release notes text edited for inclusion int he release notes. Thanks for providing the text Maciej. |
Description of problem: The start event defined like this: > <bpmn2:startEvent id="_F9AC8B12-8E75-49B5-B799-292F66270627" drools:bgcolor="#ffffff" name=""> > <bpmn2:outgoing>_A3317C84-4084-4AD3-AEC2-B05731E3F8FB</bpmn2:outgoing> > <bpmn2:timerEventDefinition id="_FNr5s2hrEeGMT7sG7hEI2w"> > <bpmn2:timeCycle xsi:type="bpmn2:tFormalExpression" id="_FNr5tGhrEeGMT7sG7hEI2w">2000</bpmn2:timeCycle> > </bpmn2:timerEventDefinition> > </bpmn2:startEvent> Version-Release number of selected component (if applicable): BRMS 5.3.0.ER4 How reproducible: always Steps to Reproduce: 1. import attached BPMN2 process into Guvnor 2. start the process in jBPM Console 3. the script nodes inside the process are executed only once Actual results: Only single start event occurs. Expected results: Start events should be emitted repeatedly every 2000ms. Additional info: