Activiti

Timer start event triggers twice

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.6
  • Fix Version/s: 5.9
  • Component/s: Engine
  • Labels:
  • Testcase included:
    yes
  • Number of attachments :
    3

Description

This bug comes from http://forums.activiti.org/en/viewtopic.php?f=6&t=2218. More information could be found there.

create a timer start event, set the time to a simple time duration, something like
<timerEventDefinition>
<timeDuration>P10D</timeDuration>
</timerEventDefinition>

and connect it to a simple service task. It is expected that the service task triggers once after the specified time.
But it is triggered twice. One at the right moment and one just when the process is started.

A test case showing the bug is attached.

  1. Text File
    act_907_1.patch
    23/Dec/11 9:57 AM
    36 kB
    saeid mirzaei
  2. Text File
    patch_act_907.patch
    20/Jan/12 6:53 AM
    1.0 kB
    saeid mirzaei
  3. File
    testTimerProject.tgz
    24/Aug/11 2:19 PM
    9 kB
    saeid mirzaei

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ronald van Kuijk added a comment -

the attachment is a .tgz.gz file (double compressed)

Show
Ronald van Kuijk added a comment - the attachment is a .tgz.gz file (double compressed)
Hide
Permalink
saeid mirzaei added a comment -

you are right, sorry. now should be usable with your comment.

Show
saeid mirzaei added a comment - you are right, sorry. now should be usable with your comment.
Hide
Permalink
saeid mirzaei added a comment -

here is a short description of root of the problem.
the start timer is parsed in parseStartEvents method in Bpmnparse. it uses the NoneStartEventActivityBehavior which is also used in normal start event. So, not strangely it is behaved like normal start event and the next activity is started just after starting instance.
After this first execution, a TimerStartEventJobHandler event handler is created by ProcessEngineConfigurationImpl.initJobExecutor. which in turn is run in building process engine and before even starting process instance. in TimerStartEventJobHandler, the instance is restarted another time using StartProcessInstanceCmd method.

So two solutions come to mind:
1. try to stop first calling
2. create a special behavior for timer start event. This behavior does nothing in execute but continues the activiti in signal method.

I think it is not also logical that the start timer event runs before starting the instance itself.
why not behave start Timer the same way as TimerCatchIntermediateEvent ?

I am not also sure that it would function correctly in case a start timer is used in a subprocess.
can any one guide for further debugging ?

– Saeid

Show
saeid mirzaei added a comment - here is a short description of root of the problem. the start timer is parsed in parseStartEvents method in Bpmnparse. it uses the NoneStartEventActivityBehavior which is also used in normal start event. So, not strangely it is behaved like normal start event and the next activity is started just after starting instance. After this first execution, a TimerStartEventJobHandler event handler is created by ProcessEngineConfigurationImpl.initJobExecutor. which in turn is run in building process engine and before even starting process instance. in TimerStartEventJobHandler, the instance is restarted another time using StartProcessInstanceCmd method. So two solutions come to mind: 1. try to stop first calling 2. create a special behavior for timer start event. This behavior does nothing in execute but continues the activiti in signal method. I think it is not also logical that the start timer event runs before starting the instance itself. why not behave start Timer the same way as TimerCatchIntermediateEvent ? I am not also sure that it would function correctly in case a start timer is used in a subprocess. can any one guide for further debugging ? – Saeid
Hide
Permalink
saeid mirzaei added a comment -

This is a patch fixing this problem. Would be great if someone can check and merge

Show
saeid mirzaei added a comment - This is a patch fixing this problem. Would be great if someone can check and merge
Hide
Permalink
saeid mirzaei added a comment -

This time Tijs Rademakers explained it clearly. It seems that it is not a real bug. The thing is that, StartProcessInstance function could only be used for none start events.Timer start events, start automatically after being deployed. it is possible to call startProcessInstance for processes starting with start timer event, but in this case, the process will start twice, once by startProcessInstance and the other time when time is reached.
The only problem is that, it is better to make this procedure, more clear in the user guide document.

Show
saeid mirzaei added a comment - This time Tijs Rademakers explained it clearly. It seems that it is not a real bug. The thing is that, StartProcessInstance function could only be used for none start events.Timer start events, start automatically after being deployed. it is possible to call startProcessInstance for processes starting with start timer event, but in this case, the process will start twice, once by startProcessInstance and the other time when time is reached. The only problem is that, it is better to make this procedure, more clear in the user guide document.
Hide
Permalink
saeid mirzaei added a comment -

Here is a proposal patch to enhance the document on this topic.

Show
saeid mirzaei added a comment - Here is a proposal patch to enhance the document on this topic.
Hide
Permalink
saeid mirzaei added a comment -

Patch to give more information to avoid misunderstanding mentioned in AC-907

Show
saeid mirzaei added a comment - Patch to give more information to avoid misunderstanding mentioned in AC-907
Hide
Permalink
Tijs Rademakers added a comment -

Applied the user guide patch

Show
Tijs Rademakers added a comment - Applied the user guide patch

People

  • Assignee:
    Tijs Rademakers
    Reporter:
    saeid mirzaei
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
10h
Original Estimate - 10 hours
Remaining:
10h
Remaining Estimate - 10 hours
Logged:
Not Specified
Time Spent - Not Specified