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!
I am not sure I understand question correctly. You want to retry whole process execution or just some asynchronous part of it?
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?
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.
Does that help you?
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.
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.
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!
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!
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
Relevant feature ticket: https://app.camunda.com/jira/browse/CAM-3236
@Webcyberrob: We discussed this once, see the linked google docs discussion
Were you able to find the global solution ??