Hi,
I am experiencing an issue with a non-interrupting timer event in my BPMN process, where the timer seems to trigger at irregular intervals instead of following its defined schedule. I am hoping to get some insights or suggestions on how to resolve this.
Process Description:
Cron Expression: The timer event is configured with the cron expression 0 0/1 * * * ?, intended to trigger every minute.
From the pic below, It’s starting before one minute cycle
your example shows an infinite recursive structure. It’s expected to get so many jobs, because each time the non interrupting timer event fires, it will create a new user task with a new attached boundary timer event while the others will stay as well and fire again.
Either make the timer event interrupting or make the sequence flow to go to an end event.
Hope this helps, Ingo
yes, as you see the cycle was set every 1 minute but some of event is start trigger before the next minute (i.e. 10:49:06, 10:49:10)
Please help suggest on this, why it happens like this behaviour.
As mentioned by @Ingo_Richtsmeier
Process Starts at Time 0.
Non-Interrupting Timer A goes off at Time 1
. . . which starts a NEW instance of Query Task
. . . (There are now 2 “Query Task” running in this process instance)
Non-Interrupting Timer A goes off at Time 2
. . . which starts a NEW instance of Query Task
. . . (There are now 3 “Query Task” running in this process instance)
Non-Interrupting Timer B goes off at Time 2.1
. . . which starts a NEW instance of Query Task
. . . (There are now 4 “Query Task” running in this process instance)
Non-Interrupting Timer A goes off at Time 3
. . . which starts a NEW instance of Query Task
. . . (There are now 5 “Query Task” running in this process instance)
Non-Interrupting Timer B goes off at Time 3.1
. . . which starts a NEW instance of Query Task
. . . (There are now 6 “Query Task” running in this process instance)
Non-Interrupting Timer C goes off at Time 3.2
. . . which starts a NEW instance of Query Task
. . . (There are now 7 “Query Task” running in this process instance)
By the time you can see Timer C, there’s a drift that is happening, and they will not longer all be firing on the same second, so they will appear to be happening “early”. This will be REALLY difficult to really see looking at the database, since they are all the same process instance, with the same task name and the same timer name.
Change the timer to an Interrupting Timer for Test #1. This will then cause:
Process Starts at Time 0.
Interrupting Timer A goes off at Time 1, which ends Query Task and starts a new one.
Interrupting Timer B goes off at Time 2, which ends Query Task and starts a new one.
Interrupting Timer C goes off at Time 3, which ends Query Task and starts a new one.
Leave the timer and a Non-Interrupting Timer, and change the workflow so the timer DOES NOT link to the Query Event and goes to its own END event instead. This will give you:
Process Starts at Time 0.
Non-Interrupting Timer A goes off at Time 1 and stops the additional flow
Non-Interrupting Timer A goes off at Time 2 and stops the additional flow
Non-Interrupting Timer A goes off at Time 3 and stops the additional flow
