Set retry time cycle for all processes

Hi Camundos,

I’d like to define the ‘Retry Time Cycle’ attribute for all processes in the bpm-platform.xml file. I’ve already know how to set the number of retries (defaultNumberOfRetries) but i’ve found no attribute in the docs to set the timeout between retries globally.

Do you have any ideas how I can achieve that?

Thanks for any hints!

Best regards,
Kerstin

Hi @kerstinguenther,

I am not sure I understand question correctly. You want to retry whole process execution or just some asynchronous part of it?

Cheers,
Askar.

Hi @aakhmerov,

thanks for your fast reply!

In our processes, we have several service tasks which call external services via REST. We don’t want to specify the same retry time cycle on each of these service task. We’d like to specifiy globally something like: Each time, a job is failed (and retries left), the job executor should wait a certain time X before executing that job again.

Is it clear now?

Best regards,
Kerstin

Hi @kerstinguenther,

the way I understand it, right now you cannot do something like that out of the box. What you could do for example is to provide custom implementation of org.camunda.bpm.engine.impl.bpmn.parser.FoxFailedJobParseListener#setFailedJobRetryTimeCycleValue and set retry cycle to your “default” value on elements during parsing. This is a bit hacky, but should work.

Or implement a start listener which will set custom default value into variable, which is used as a retry cycle.
https://docs.camunda.org/manual/7.5/reference/bpmn20/events/timer-events/#expressions

Does that help you?
Askar

Hi Askar,

Perhaps theres a feature request opportunity here - The ability to configure a default retry strategy, ie number of retries and over what duration. At the moment, the engine implementation seems to have defined this (three agressive retries) and I have not found a way to configure this.

regards

Rob

Hi Rob,

sure, that sounds right, you can always create a feature request ticket in our JIRA. With that said, there is no guarantee on when it will be implemented.

You can also provide a pull request with implementation, if you would like to.

Cheers,
Askar

Hi @aakhmerov,

as a workaround, we could set the attribut lockTimeInMillis in the process engine configuration. In that way LOCK_EXP_TIME_ will be set and a job will not be retried as soon as that time is expired.

Are there any drawbacks using that approach?

We would set the lock time to 5 seconds (with 3 retries) to outlast server restarts of external services we are using. Our processes are long running (black box) processes. Therefore it doesn’t matter if jobs will take a bit longer.

Thanks for your feedback!

Best regards,
Kerstin

Hi Kerstin,

maybe this example snippet may help you: https://github.com/camunda/camunda-consulting/tree/master/snippets/change-job-retry.

Cheers, Ingo

Hi Ingo,

thanks for your hint with a code snippet!

The approach is similar to the one mentioned at first hand from @aakhmerov.
In both cases, implementation of new classes is needed.

We’d like to simply change settings in the bpm-platform.xml. But we want to be aware off all side effects changing lockTimeInMillis in the process engine configuration.

Thanks for any feedback regarding that global change!

Best regards,
Kerstin

Hi @kerstinguenther,

I am not sure that will do what you want, by default if you don’t have custom failure strategy lock expiry time will be simply reset see org.camunda.bpm.engine.impl.cmd.DecrementJobRetriesCmd.

Cheers,
Askar

Hi all,

Relevant feature ticket: https://app.camunda.com/jira/browse/CAM-3236
@Webcyberrob: We discussed this once, see the linked google docs discussion :slight_smile:

Cheers,
Thorben

1 Like

Were you able to find the global solution ??