hi，
I am using camunda7.17.0.
During the execution process, I found that when the task was executed to LOCK_EXP_TIME is reached, a retry will be triggered. So I tried to set the retry count to 0 when starting the process, and then the process reached LOCK_EXP_TIME, there is no retry, but the process cannot continue.
I wonder if I can monitor this LOCK_ EXP_ TIME, then stop the process after arrival LOCK_ EXP_ TIME. Or can I rewrite the retry strategy? Stop the process without retry.
Maybe I don’t understand your question correctly, so let me try to elaborate on what I think you’re asking about.
The lock expiration time of a job has nothing in so far to do with the retry count. If a job is fetched by a worker, it’s locked by this worker by setting values into the columns LOCK_EXP_TIME_ and LOCK_OWNER_ in the table ACT_RU_JOB.
Once the lock expiration time is reached, the job can be locked again by another worker, as the other worker somehow failed to complete the job (maybe due to a crash).
The retry count on the other hand is decreased, once a job worker has an exception while trying to execute a job. When the retry count reaches zero, the job won’t be retried again without manual intervention.
Conceptually (but not 100% accurate):
@spacehouse If you set the retries to 0, as long as the job is not failed, it should simply return to the queue, and another (or the same) worker can pick it back up again to try the job. If your external worker sends a FailJob back because the service that it’s working with didn’t reply in time, and the retries is 0, then an incident will be raised and manual intervention would be required to start the process back up again.
That is what I meant. Those are two different things. Locks are all about whether a job is available for execution by a worker (or currently locked by some worker).
On the other hand the retry count is used to determine whether a failed job should be retried or will raise an incident (when retry count is zero).
@rohwerj @GotnOGuts Thank you very much for your reply. I did make a mistake. It is not the retry that causes the job to repeat. It is the periodic scheduling of ‘AcquireJobsCmd’. After the job reached the LOCK_EXP_TIME_, it becomes acquirable. Then it can be picked up by the AcquireJobsCmd scheduling and executed in another thread. Even though the job has not yet completed.
Now, I want to know what I can do when a job reaches its LOCK_EXP_TIME_?
@spacehouse Are we talking about an external task? In that case you worker could extend the lock, when it needs more time to execute the task.
If it’s not an external task, you could either change the property lock-time-in-millis in the configuration of the job executor or switch to an external task to have a more fine grained possibility to extend the lock (as shown above).
Here the link to the configuration of the job executor for a spring boot application: