Activiti creates new act_ru_job entries for timed task

[danielbreitner]

Hello everybody,

We are using activiti 5.10 and we are noticing a very strange behaviour for activiti timed tasks:

We have a timed task that wakes up every 30 seconds, checks if "work" needs to be done and if so, it does this work and finishes itself. If no work is to be done, it finishes itself.

This all works without any exceptions or "hickups".

The problem that we have, is that activiti creates new instances of this timed event occasionally. This means that another entry in the table "act_ru_job" is created for this process definition. So instead of one timed task doing the work, we now have two. And after a month we already have more then 100.

This doesn´t happen every time, sometimes there are two week where nothing happens. There are no exceptions, and the task table (act_ru_task) shows me that there are no tasks waiting for completion. The procdef table shows me, that there really is only one process deployed that contains the timed task.

I know that this is really a strange error, and that it is pretty hard to solve it without any exceptions but maybe someone here has experienced the same or could lead me to an official bug description.

Best regards,

Dan

[jbarrez]

Wow that indeed sounds really strange….

And you do see two timers in the act_ru_job?

The only thing that I can think of is that the time to execute the timer (ie to execute the 'work') takes longer than the time between two consequential checks? Could that be the case?

[danielbreitner]

Hi,

yes, I do see 102 timers in ACT_RU_JOB

Yesterday we cleaned up the mess by reinitializing the complete database and we eagerly await the next timers to appear.

The work always takes longer then the time between the checks.
But this hasn´t been an issue so far and I also couldn´t reproduce it.
Normally activiti is able to cope with that.


Is there any documentation for in which situations activiti creates new timers in the database ?

[jbarrez]

The work always takes longer then the time between the checks.
But this hasn´t been an issue so far and I also couldn´t reproduce it.
Normally activiti is able to cope with that.

Yes, it should indeed be able to cope with that. But my gut feeling tells me that for some reason in specific cases a new timer is created somehow.

Is there any documentation for in which situations activiti creates new timers in the database ?

The only occasions when a timer is created:
- A timer start event creates a timer on process definition deployment
- A timer definition in the process instance is encountered (intermediary timer / boundary event)
- A timer is recurring, has fired and need to reinitiate himself/

I'm sorry I can't provide more assistance with this issue … it would really be helpful if you can pinpoint the exact situation when it goes wrong.

[danielbreitner]

Ok, we have 2 more timers now (within 24 hours).

Is there a log statement that will be written when a new timer is created ? Currently I don´t even know when those timers are created.

The only occasions when a timer is created:
- A timer start event creates a timer on process definition deployment
- A timer definition in the process instance is encountered (intermediary timer / boundary event)
- A timer is recurring, has fired and need to reinitiate himself/

1) We have activiti running in a tomcat. It is deployed and unpacked but the WAR is still in the webapps folder  - can this create this confusion ?

2) When does a timer has to reinitialize itself ? In which occasions ? Will I be able to see any logging statements ?

[jbarrez]

Is there a log statement that will be written when a new timer is created ? Currently I don´t even know when those timers are created.

That's a pretty low level (SQL) log, you'd have to set the level of logging to debug to see it. Something like this: https://github.com/Activiti/Activiti/blob/master/modules/activiti-engine/src/test/resources/log4j.pr...

You probably will need to lower the ibatis logging too in that same file. Do take in account a HUGE amount of logging will be generated

1) We have activiti running in a tomcat. It is deployed and unpacked but the WAR is still in the webapps folder - can this create this confusion ?

No, this can't create problems. Tomcat is smart enough to know the folder is the exploded version of the war.

2) When does a timer has to reinitialize itself ? In which occasions ? Will I be able to see any logging statements ?

Only when it is a timer with a repeat. (which was the case, as I understood it?).
Or does your process go into an intermediary timer again and again.

Can you share your process? Might be something there (altough I doubt it, as it doesn't happen every time)