Skip to content

Queues Strategy

Jump to bottom
Júlio Falbo edited this page Dec 1, 2019 · 2 revisions

By default, RabbitMQ does not provide a retry strategy that we can control all the life cycle of the message.

For example, until RabbitMQ 3.8, we do not have a property in the header to control the number of retries that Rabbit already did.

RabbitMQ default behavior:

  • If you didn't define the time-to-live argument, RabbitMQ will try to requeue your message forever.
  • If you defined a ttl but didn't define a dlx, after ttl, RabbitMQ will remove your message to the queue and you will lose the message.
  • If you defined a ttl and a dlx, after the ttl, RabbitMQ will send the message to the exchange defined in the dlx.

Default RabbitMQ Behavior

So, but if we want to have a growing ttl (in case of instability, for example), and control the number of retries, how can we do this?

Default Spring AMQP

With Spring AMQP default, you can define retry configurations using the properties below, when simple is the default container bean.

But this strategy has a problem. By default, Spring AMQP will lock your queue when it tries to deliver the message in the retry process.

To resolve this has a workaround that is: Define the concurrency. But this way we are overload the JVM, and is not the best approach, and we still need to define the beans manually in our @Configuration bean for each connection and container.

spring.rabbitmq.listener.simple.retry.enabled=true
spring.rabbitmq.listener.simple.retry.initial-interval=2000
spring.rabbitmq.listener.simple.retry.max-attempts=5
spring.rabbitmq.listener.simple.retry.multiplier=2
spring.rabbitmq.listener.simple.max-concurrency=5
spring.rabbitmq.listener.simple.concurrency=5

Tradeshift Spring AMQP Lib

This library creates a strategy using another queue for retries. With this, we can control the ttl using the expiration message property and we can use the x-death message property to control the number of retries.

But how?

We are using the dlx concept in the retry queue to requeue a message in the main queue. Doing this, we have access to the x-death property and we can define programmatically the message expiration.

Note: How this lib is an extension of Spring AMQP, if you want to use the default retry strategy, you can still use this lib only for auto configurations of beans.

Tradeshift RabbitMQ Behavior

Clone this wiki locally