Best practices for handling rejected messages in case of unhandled errors in consumers

[AM]

Regarding what to do with a consumed message (ack, reject or requeue), I see these patterns

1. The message is successfully handled => send ACK

2. The message cannot be deserialized => log the issue, reject the message without requeuing so the message is sent to the dead letter;

3. The message is old, no need for handling it => do nothing and ack the message

4. While handling the message, a transient problem happens (for example, an external system is unavailable). It is likely that the message can be handled later => reject and requeue, possibly after a delay for retry.

I need a suggestion for a 5th case: what should a subscriber do with a message, in case an unhandled exception raises, for example in case of a NullPointerException caused by a bug?

Of course the subscriber cannot proceed with handling the message, and it should reject it. The question is, should it requeue the message?

I see those 2 options:

1. The consumer logs the problem, then rejects the message requeuing it. 

Pros: this makes sense, because there’s nothing wrong in the message itself; it is just the consumer that has some bugs and raised an exceptional case it is not able to handle.

Cons: The message will be redelivered just after that, so there it is very likely that after few milliseconds the same error will raise, causing a flood of error messages in the log. May be a circuit breaker must be put in place.

2. The consumer rejects the message, without requeueing it. If the queue has a dead letter exchange, the message will be sent to an error queue.

Pros: there won’t be any flood in the logs: the error will be reported once.

Cons: there is the risk that for a bug the consumer will send all the messages in the error queue.

[Laing, Michael]

We usually do 1) if the msg redelivered flag is not set and 2) if the msg redelivered flag is set, i.e. it has failed once before or something else is screwy.

For most services, we restart them in the case of 2. We always have multiple copies of services consuming from the same queue.

ml

--
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.