63

I am using RabbitMQ server.

For publishing messages, I set the immediate field to true and tried sending 50,000 messages. Using rabbitmqctl list_queues, I saw that the number of messages in the queue was zero.

Then, I changed the immediate flag to false and again tried sending 50,000 messages. Using rabbitmqctl list_queues, I saw that a total of 100,000 messages were in queues (till now, no consumer was present).

After that, I started a consumer and it consumed all the 100,000 messages.

Can anybody please help me in understanding about the immediate bit field and this behavior too? Also, I could not understand the concept of the mandatory bit field.

Pang
  • 9,564
  • 146
  • 81
  • 122
Gurpreet Singh
  • 1,326
  • 3
  • 15
  • 21

2 Answers2

143

The immediate and mandatory fields are part of the AMQP specification, and are also covered in the RabbitMQ FAQ to clarify how its implementers interpreted their meaning:

Mandatory

This flag tells the server how to react if a message cannot be routed to a queue. Specifically, if mandatory is set and after running the bindings the message was placed on zero queues then the message is returned to the sender (with a basic.return). If mandatory had not been set under the same circumstances the server would silently drop the message.

Or in my words, "Put this message on at least one queue. If you can't, send it back to me."

Immediate

For a message published with immediate set, if a matching queue has ready consumers then one of them will have the message routed to it. If the lucky consumer crashes before ack'ing receipt the message will be requeued and/or delivered to other consumers on that queue (if there's no crash the messaged is ack'ed and it's all done as per normal). If, however, a matching queue has zero ready consumers the message will not be enqueued for subsequent redelivery on from that queue. Only if all of the matching queues have no ready consumers that the message is returned to the sender (via basic.return).

Or in my words, "If there is at least one consumer connected to my queue that can take delivery of a message right this moment, deliver this message to them immediately. If there are no consumers connected then there's no point in having my message consumed later and they'll never see it. They snooze, they lose."

Brian Kelly
  • 19,067
  • 4
  • 53
  • 55
  • 2
    What happens if the lucky consumer crashes before acking the receipt and there are no other consumers on the queue? Does the message still just sit in the queue? Or does it get returned? – nornagon Apr 28 '14 at 22:45
  • I did not test it, but I can guess that crashed consumer is another story, and the behaviour of that related to requeueing or dead letter. – Shay Tsadok Jan 10 '16 at 15:27
  • Sorry to add a comment almost 5 years later... It looks to me that the `immediate` flag is not exposed through RabbitMQ's API? At least not in the .Net API. The only way I found that the `immediate` flag is settable in the library is through an internal `BasicPublish` class's constructor that's never used in the library. Is `immediate` in some way deprecated or discouraged? – Niall Connaughton Feb 18 '16 at 04:38
  • 13
    Ah, found the answer to my question: [immediate was removed in Rabbit v3.0](http://www.rabbitmq.com/blog/2012/11/19/breaking-things-with-rabbitmq-3-0/) because it was rarely used, complicated the codebase and had an alternative. – Niall Connaughton Feb 18 '16 at 04:42
  • 3
    loved the "Or in my words". I wish all tech specs were like that :) – Anand May 05 '20 at 13:31
17

http://www.rabbitmq.com/blog/2012/11/19/breaking-things-with-rabbitmq-3-0/

Removal of "immediate" flag

What changed? We removed support for the rarely-used "immediate" flag on AMQP's basic.publish.

Why on earth did you do that? Support for "immediate" made many parts of the codebase more complex, particularly around mirrored queues. It also stood in the way of our being able to deliver substantial performance improvements in mirrored queues.

What do I need to do? If you just want to be able to publish messages that will be dropped if they are not consumed immediately, you can publish to a queue with a TTL of 0.

If you also need your publisher to be able to determine that this has happened, you can also use the DLX feature to route such messages to another queue, from which the publisher can consume them.

Just copied the announcement here for a quick reference.

Community
  • 1
  • 1
themefield
  • 3,847
  • 30
  • 32