RabbitMQ - Does one consumer block other consumers of the same queue?

Question

I am involved in teaching RabbitMQ / AMQP from the RabbitMQ documentation. Something that I do not understand that I wanted to ask those who have practical experience. I want several consumers to listen to the same queue in order to balance workload. What I need is very close to the Work Queues example in the RabbitMQ tutorial . I want the consumer to explicitly acknowledge the message after he has finished processing it in order to save the message and transfer it to another consumer in case of failure. Processing a message may take some time. My question is, does AMQP delay the next processing of the message until the previous message appears? If so, how do I achieve a load balance between several workers and ensure that no messages get lost?

Answer 1

No, other consumers are not blocked. Other messages will be delivered, even if they have unconfirmed but delivered predecessors. If the channel closes when unacknowledged messages are saved, these messages are returned to the queue.

See RabbitMQ Brokerage Semantics

Messages can be returned to the queue using AMQP methods that have the requeue parameter (basic.recover, basic.reject and basic.nack) or because the channel is closed while saving unconfirmed messages.

---

EDIT In response to your comment:

Time to dive a little into the AMQP specification , perhaps it’s possible:

3.1.4 Message Queues

A message queue is a named FIFO buffer that contains a message on behalf of a set of consumer applications. Applications can freely create, share, use and destroy message queues within their authority. Please note that in the presence of several readers from the queue or client transactions or using priority fields, or using message selectors, or optimizing delivery for implementation, the queue CANNOT demonstrate the true FIFO characteristics. The only way to guarantee FIFO is to have only one consumer connected to the queue. In these cases, the queue can be described as “weak-FIFO”. [...]

3.1.8 Acknowledgments

A confirmation is a formal signal from the client application to the message queue, which has successfully processed the message. [...]

Thus, confirmation confirms processing, not receipt. The broker will adhere to the message until it is received so that it can re-add them. But it can provide more messages to consumers, even if preliminary messages have not yet been confirmed. Consumers will not be blocked.