Bug 801093 - Timer start event does not emit start events repeatedly (in jBPM Console)
Timer start event does not emit start events repeatedly (in jBPM Console)
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM Console (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity unspecified
: ER6
: BRMS 5.3.0.GA
Assigned To: Maciej Swiderski
Marek Baluch
: 811986 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-03-07 11:36 EST by Jiri Locker
Modified: 2015-06-01 21:39 EDT (History)
5 users (show)

See Also:
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:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
TimerProcess.bpmn2 (5.41 KB, application/xml)
2012-03-07 11:39 EST, Jiri Locker
no flags Details

  None (edit)
Description Jiri Locker 2012-03-07 11:36:12 EST
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:

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:
Comment 1 Jiri Locker 2012-03-07 11:39:58 EST
Created attachment 568349 [details]
Comment 4 Jiri Locker 2012-04-12 09:33:03 EDT
*** Bug 811986 has been marked as a duplicate of this bug. ***
Comment 5 Jiri Locker 2012-04-12 09:35:15 EDT
This issue affects any timer node (not only start event timer). That's why I filed the duplicate issue.
Comment 6 Kris Verlaenen 2012-04-13 13:00:55 EDT
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.
Comment 7 Ryan Zhang 2012-04-23 03:35:50 EDT
Update status to ON_QA. Please verify them against ER6.
Comment 8 Tomas Schlosser 2012-06-21 04:37:28 EDT
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.
Comment 9 Maciej Swiderski 2012-08-22 10:20:42 EDT
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.
Comment 10 Maciej Swiderski 2012-08-23 10:36:46 EDT
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
Comment 11 Maciej Swiderski 2012-08-30 11:40:47 EDT
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
Comment 12 Maciej Swiderski 2012-08-31 12:28:54 EDT
merged into master and 5.2.x
Comment 13 Mario Fusco 2012-08-31 14:24:01 EDT
Edson fixed the timer serialization with this commit:


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:

Comment 14 Maciej Swiderski 2012-09-03 10:33:40 EDT
based on discussion on IRC all timer bugs are fixed
Comment 15 Jiri Svitak 2012-10-03 11:33:04 EDT
Verified in BRMS 5.3.1 ER1.
Comment 16 lcarlon 2012-10-21 22:46:58 EDT
Release notes text edited for inclusion int he release notes. Thanks for providing the text Maciej.

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