Hi!
What is the expected behaviour for a retry cycle on a timer in terms of the creation of a Due Date and Retry Duration?
Example:
You have a Timer with a cycle of PT/1M. You have a Retry Cycle of R/PT5M.
The timer is a non-interrupting timer attached to a user task.
When the Timer executes the first time and fails (for whatever reason), the retry will kick in for the timer job. How does this interact in terms of threads and job executor?
Hi Stephen,
Timer is Async, so yes it runs in job exec thread. Timer has a due date when it becomes available as a job. If it fails in the job executor thread, retry strategy kicks in. The current executor thread should update the job due date based on retry strategy, decrement the retry count and relinquish the lease on the job. Thus a new job exec thread will lease the job when it becomes due again…
At least that’s what I understand should happen. Do you concurr?
Regards
Rob
I was investing a case where the retry count was exponentially high: such as in the hundreds of millions of retries (even with the max retries still at 3). But unclear what could cause it. I was thinking there was a endless sync retry loop occurring. Still investigating trying to recreate the conditions.
Wow, cosmic rays corrupting memory? I’ve had one of these unexplained events once in my life, batch processing interest on bank accounts…so in a repeatable loop of hundreds of thousands of accounts, one calculation went awry. On investigation, the data used for that record in the calculation was fine…
Let me know if you get any more insight, curious…
Regards
Rob