Activiti

Allow engine to configure a delay between retries and the amount of retries.

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.8
  • Fix Version/s: 5.10
  • Component/s: Engine
  • Labels:
    None
  • Number of attachments :
    3

Description

Currently if job execution fail then next execution is made immadiate (three times until sucessfull).
There can be a small delay depending from the amount of jobs waiting for execution but i think it is insufficient.

We need more configuration, firs for all:

  • the delay between each retry
  • configurable the amount of retries

Both values should be configured in JobExecutor.

i think to allow configure delay between each retries is required a new column NEXT_ATTEMPT_TIME in ACT_RU_JOB table.
It should be filled and calculeted during job aquisition and recalculated in DecrementJobRetriesCmd after each fail.

  1. Text File
    ACT-1046_v2.patch
    13/Jan/12 6:22 AM
    31 kB
    Dawid Wrzosek
  2. Text File
    ACT-1046_v3.patch
    06/Feb/12 9:11 AM
    12 kB
    Dawid Wrzosek
  3. Text File
    ACT-1046.patch
    12/Jan/12 7:37 AM
    21 kB
    Dawid Wrzosek

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tom Baeyens added a comment -

this looks like a low risk change.

Show
Tom Baeyens added a comment - this looks like a low risk change.
Hide
Permalink
Joram Barrez added a comment -

Agreed, good addition.

Show
Joram Barrez added a comment - Agreed, good addition.
Hide
Permalink
Tom Baeyens added a comment -

Go for it. David, would be good if you could create a patch or a branch for this.

Show
Tom Baeyens added a comment - Go for it. David, would be good if you could create a patch or a branch for this.
Hide
Permalink
Dawid Wrzosek added a comment - - edited

I'm working on it and i'm going to prepare a patch.

Show
Dawid Wrzosek added a comment - - edited I'm working on it and i'm going to prepare a patch.
Hide
Permalink
Dawid Wrzosek added a comment - - edited

I added the patch for this issue. The delay between each retry and amount of retries can be configured through the new JobExecutor fields:

  • amountOfRetries
  • retriesDelayInMills

I left current behaviour without changes (if job execution fail then next execution is made immadiate (three times until sucessfull)).

Show
Dawid Wrzosek added a comment - - edited I added the patch for this issue. The delay between each retry and amount of retries can be configured through the new JobExecutor fields: amountOfRetries retriesDelayInMills I left current behaviour without changes (if job execution fail then next execution is made immadiate (three times until sucessfull)).
Hide
Permalink
Dawid Wrzosek added a comment -

I added a new version of the patch. The previous version has a lot of conflicts with trunk (commited refactoring of the JobExecutor : ACT-34).

Show
Dawid Wrzosek added a comment - I added a new version of the patch. The previous version has a lot of conflicts with trunk (commited refactoring of the JobExecutor : ACT-34 ).
Hide
Permalink
Daniel Meyer (camunda) added a comment -

Why do you need a new db column for this? Why do you not simply set the lockExpirationTime to the desired interval?

Show
Daniel Meyer (camunda) added a comment - Why do you need a new db column for this? Why do you not simply set the lockExpirationTime to the desired interval?
Hide
Permalink
Dawid Wrzosek added a comment -

Do you think about set the lockExpirationTime after job fails ?
Simply: if job execution fails then set the lockExpirationTime to a current timstamp plus retriesDelayInMills.

Show
Dawid Wrzosek added a comment - Do you think about set the lockExpirationTime after job fails ? Simply: if job execution fails then set the lockExpirationTime to a current timstamp plus retriesDelayInMills.
Hide
Permalink
Daniel Meyer (camunda) added a comment -

Yes that is what I was thinking of. Wouldn't that be much simpler and require a lot less changes?
(Maybe I'm missing something)

Show
Daniel Meyer (camunda) added a comment - Yes that is what I was thinking of. Wouldn't that be much simpler and require a lot less changes? (Maybe I'm missing something)
Hide
Permalink
Dawid Wrzosek added a comment -

I agree with you. Unnecessarily i wanted to separate those values. I'm going to change the patch and attach it today.
Do you have any other suggestion ?

Show
Dawid Wrzosek added a comment - I agree with you. Unnecessarily i wanted to separate those values. I'm going to change the patch and attach it today. Do you have any other suggestion ?
Hide
Permalink
Dawid Wrzosek added a comment -

Modified patch attached.
When can we expect this patch on the trunk ?

Show
Dawid Wrzosek added a comment - Modified patch attached. When can we expect this patch on the trunk ?
Hide
Permalink
Daniel Meyer (camunda) added a comment -

Hi Dawid,

this is a good addition. I'll try to have a look at it until he end of the week.

Show
Daniel Meyer (camunda) added a comment - Hi Dawid, this is a good addition. I'll try to have a look at it until he end of the week.
Hide
Permalink
Roman Smirnov (camunda) added a comment -

In discussion with Daniel we found another way to handle the configuration of a delay between retries and the amount of retries.

For that we provide a listener "FailedJobListener" and an interface "FailedJobCommandFactory". The "FailedJobListener" replaces the "DecrementJobRetriesListener" which previously was used in the class "ExecuteJobsCmd". The new listener uses the factory to create an instance of a command to handle a failed job. Activiti uses by default the "DefaultJobCommandFactory" which implements the new interface to create an instance of the command "DecrementJobRetriesCmd" to provide the logic as previously.

Now you can implement your own strategy to handle failed jobs. For example you can implement a strategy to distinguish between the type of the failed job and handle them differently (e.g. set another delay or the the amount of retries).

See revision: 3372

Show
Roman Smirnov (camunda) added a comment - In discussion with Daniel we found another way to handle the configuration of a delay between retries and the amount of retries. For that we provide a listener "FailedJobListener" and an interface "FailedJobCommandFactory". The "FailedJobListener" replaces the "DecrementJobRetriesListener" which previously was used in the class "ExecuteJobsCmd". The new listener uses the factory to create an instance of a command to handle a failed job. Activiti uses by default the "DefaultJobCommandFactory" which implements the new interface to create an instance of the command "DecrementJobRetriesCmd" to provide the logic as previously. Now you can implement your own strategy to handle failed jobs. For example you can implement a strategy to distinguish between the type of the failed job and handle them differently (e.g. set another delay or the the amount of retries). See revision: 3372
Hide
Permalink
Bernd Ruecker (camunda) added a comment -

I consider this as done. As an example (and proof ) we hooked in a more powerful strategy in the fox ee version: https://app.camunda.com/confluence/display/foxUserGuide/Custom+Job+Retry+Strategy

Show
Bernd Ruecker (camunda) added a comment - I consider this as done. As an example (and proof ) we hooked in a more powerful strategy in the fox ee version: https://app.camunda.com/confluence/display/foxUserGuide/Custom+Job+Retry+Strategy

People

  • Assignee:
    Daniel Meyer (camunda)
    Reporter:
    Dawid Wrzosek
Vote (4)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved: