Places copy of message into a queue with "op-rabbit.abandoned." prepended (configurable); after ttl (default of 1 day), these messages are dropped.
Places copy of message into a queue with "op-rabbit.abandoned." prepended (configurable); after ttl (default of 1
day), these messages are dropped. Exception is stored in x-exception
header; original routing information stored
in x-original-routing-key
and x-original-exchange
.
- How long abandoned messages should stay in the queue.
Recovery strategy which redelivers messages a limited number of times.
Recovery strategy which redelivers messages a limited number of times. Violates message ordering guarantees.
For a definition of what constitutes failure, see RecoveryStrategy.
In the event of a failure, the following happens:
x-retry
is read to determine if there are retries remaining.onAbandon
handler.retryQueue
. It is of
vital importance that you read the queue caveats related noted below.x-retry
is incremented.channel.basicPublish
. Sometime after, using the same channel, the
original message is acknowledged, using the same channel. This means two things:1) The publish could succeed and the acknowledgement could fail, leading to a duplication of the message. An IO exception or network event at the right time could cause this.
2) In certain clustering configurations, it might be possible for the basicPublish to fail, but the acknowledgement to succeed. The failure case would require that the the message queue and the redelivery queue are on different cluster nodes, and that one can be reached but the other is not. Plan as needed. An implementation using transactions (slow) / asynchronous publisher confirms (faster) may be warranted.
x-original-routing-key
for
the original routing key.The retry queue is created passively. This allows the retryQueue to be used without error in the case of a
configuration change (in cases where a crash would be worse), but means that configuration changes done after the
initial creation of the queue will not propagate. As a result, if you want to guarantee that changes made to your
redelivery strategy propagate that you modify retryQueueName
function such that it will create a new redelivery
queue. The old, unused one will expire, after an idle period of redeliveryDelay * 3
.
Also, it is vitally important that for every input queue-name of the retryQueueName
, a unique value is returned.
In other words, DO NOT TRY AND CONSOLIDATE REDELIVERY QUEUES.
The number of times to retry. A value of 3 will result in 4 attempts, including the initial.
The strategy to be used once the retryCount is exhausted. Defaults to nack(false)
.
Nack (reject) the message.
Nack (reject) the message.
Whether the message should be requeued for delivery. Note: true could cause an infinite loop
No recovery strategy; cause the consumer to shutdown with an exception.
directive which extracts the x-original-exchange, if present.
directive which extracts the x-original-exchange, if present. Falls back to envelope exchange.
directive which extracts the x-original-routing-key, if present.
directive which extracts the x-original-routing-key, if present. Falls back to envelope routing key.
Header at which the formatted exception is stored.
The original exchange used before redeliver attempts
The original routing key before redeliver attempts
The message header used to track retry attempts.