This message was deleted.

I agree the entire concept of retries is the most confusing subject there is and it must be re-written for sure. When you use

negativeAckRedeliveryBackoff

then you need to know this is implemented client-side, not server side. The client saves those messages in-memory until it’s time and then send negativeAck request for that message, which then are re-sent from the broker back to the client. This negative-ack redelivery (retry) is meant when you explicitly know you failed and need a retry. The

ackTimeoutRedeliveryBackoff

serves a completely different purpose. What if your application is “stuck” for various reasons and have not acknowledged (ack or nack) a message for a given time-frame. If this is the case, you want to automatically redeliver it so you re-try. The

enableRetry

and

deadLetterPolicy

serves the explicit retry - you know you failed and want to retry, BUT if you want to control when and you most importantly you don’t want it client-side but you want it server-side and you’re ok with paying the price of saving another message for each retry. When you call

reconsumeLater

the client acks the original message and writes a new message, which is a copy of the original message (+ some metdata retry fields) to a retry topic (for a good reasons as you don’t want other subscriptions reading your retry attempts). If all retries have been exhausted, the message is written to a dead-letter topic. Bare in mind this ack and write a new message is not wrapped in a transaction for the moment (from performance standpoint) hence there is a chance the ack will fail not persist server-side but the message will be written successfully to the retry topic.

Thanks Asaf! that’s really helpful.

use

negativeAckRedeliveryBackoff

then you need to know this is implemented client-side, not server side.

How about

ackTimeoutRedeliveryBackoff

? is it server or client side?

but you want it server-side and you’re ok with paying the price of saving another message for each retry.

So why would I pay the price then? Do you mean the

negativeAckRedeliveryBackoff

+

ackTimeoutRedeliveryBackoff

doesn’t work for some scenarios or have some overhead? Otherwise why don’t I just do

negativeAckRedeliveryBackoff

+

ackTimeoutRedeliveryBackoff

? Also is there no default value for

negativeAckRedeliveryBackoff

/

ackTimeoutRedeliveryBackoff

?

ackTimeout is client side as well. It just sets a timer on the client and sends a negative ack to the server