Currently only immediate retry logic is supported. Which works for transient faults but not longer problems such as excess load or a resource being down temporarily. SLR provides progressive back-off for a configurable period of time. Example:
Try one:
First level retry (failed)
Wait 1 minute (should sent back to queue)
Try two:
First level retry (failed)
Wait 5 minutes (should be sent back to queue)
Try three:
First level retry (failed)
Wait 30 minutes (should be sent back to queue)
Try four:
First level retry (failed)
Dead-letter
Possible solutions include:
- Using Defer method of ASB - however this requires the system to record an Id to get the message again. This doesn't seem like a great option.
- Renew peek-lock - issue with this method is that its not configurable on a per message basis. As such it could get complex to track and lock period may exceed initial back off period.
- ScheduledEnqueue - allows for messages to be enqueued at a later time. This may require the removal and re-sending of the message again. Given its to the same queue (for azure) this should be able to be atomic. This seems like the most viable solution.
Currently only immediate retry logic is supported. Which works for transient faults but not longer problems such as excess load or a resource being down temporarily. SLR provides progressive back-off for a configurable period of time. Example:
Try one:
First level retry (failed)
Wait 1 minute (should sent back to queue)
Try two:
First level retry (failed)
Wait 5 minutes (should be sent back to queue)
Try three:
First level retry (failed)
Wait 30 minutes (should be sent back to queue)
Try four:
First level retry (failed)
Dead-letter
Possible solutions include: