I am looking for a good way to implement retries with a backoff policy using spring amqp and Rabbit MQ, but the requirement is that the listener should not be blocked (so it is free to process other messages). I see a similar question asked/answered on StackOverflow but it does not include the solution for 'backing off':
RabbitMQ & Spring amqp retry without blocking consumers
The questions I have are:
Does the default spring-retry implementation block threads while retrying? The implementation in github indicates that it does.
If the assumption above is true, is the only way to do this implementing a separate queue for retries (DLQ?), and setting a TTL for each message (assuming we don't want to block threads for the backoff interval).
If we go with the approach above (DLQ or a separate queue), won't we need separate queues for each retry attempt? If we use just 1 queue for retries, the same queue will contain messages with a TTL ranging from minimum retry interval to maximum retry interval, and if the message at the front of the queue has the max TTL, the message behind it will not be picked up even if it has min TTL. This is per the Rabbit MQ TTL documentation here (see Caveats):
Is there another way to implement a non-blocking Backoff Retry mechanism?
--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.