4 ms·
Based on my experience with RabbitMQ, failed messages (ie. unacked due to consumer crash) have a retry count property that is maintained by the broker. If the
by glenjamin 13y ago
Based on my experience with RabbitMQ, failed messages (ie. unacked due to consumer crash) have a retry count property that is maintained by the broker.
If the consumer simply checked if the retry count was above a threshold, and then redirected the message to a dead-letter-exchange, this would solve the "stuck message" problem.
As for tracking build up of messages, this is just a case of adding something like a nagios check on size of queue.
It seems like the solution outlined in the post is just implementing by hand the features of a decent message broker they chose not to use.
Sounds like they managed to get the job done regardless.
- twic 13y agoI don't think RabbitMQ has a retry count. It has a retry flag, which tells you if this is the first time a message has gone out for delivery, or an attempt at a redelivery. You can use that to requeue after the first failure, but to reject (and send to a dead-letter queue) after the second. But you can't do anything more than that without manually managing a count. At least, that's the conclusion i came to when i looked at redelivery for an application i work on that uses RabbitMQ. Please do correct me if i'm wrong.
- glenjamin 13y agoYou are correct, I was mistaken. https://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.deliver https://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.del... The spec has a SHOULD for aborting after a retry count, but it doesn't appear to be exposed to clients.