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.
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.
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.
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.
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 org.camunda.bpm.engine.impl.cmd.DecrementJobRetriesCmd.