AMQP: Basic.Publish immediate versus mandatory

转载：http://bunnyamqp.wordpress.com/2009/08/21/amqp-basic-publish-immediate-versus-mandatory/

 

I was unclear about the difference between the mandatory and immediate options for the AMQP Basic.Publish method, so I did a little investigation with Bunny and RabbitMQ.

It turns out that the difference is pretty straightforward. If you publish a message with the :mandatory option set to true like so -

my_exchange.publish('Test message', :mandatory => true)

Then your message will be returned unless it can be routed to a queue.

However, if you publish a message with the :immediate option set to true, as in this example -

my_exchange.publish('Test message', :immediate => true)

Then your message will be returned unless it can be consumed from a queue very quickly. I don’t know exactly how long the message can remain in the queue before it is returned, but it is necessarily a short time.

IMPORTANT: If you use either of these options with Exchange#publish in Bunny, you must check whether or not your message has been returned after you make the publish call, otherwise return messages will build up and problems will ensue. With Bunny you can check for returned messages by placing something similar to the following after your publish call -

returned_msg = my_client.returned_message

The Client#returned_message method takes an optional :timeout argument (default value is 0.1 seconds). This allows you to specify how long the method will wait to receive a returned message should the default value prove to be problematic.

If there is a returned message the method returns a hash containing :header, :payload and :return_details. The payload contains the message contents. If there is no returned message the method returns the symbol :no_return.

 

 

2 Responses to “AMQP: Basic.Publish immediate versus mandatory”

Hey Chris,

Mandatory and immediate are meant to let an application detect specific kinds of wiring problems. So the “mandatory” flag is used for SOAs where you expect a routing key to properly get resolved to some queue. I.e. the service is present and registered, as a binding on the exchange. This lets apps do things like “send to service A, and if that service does not exist, send an alert to service B”.

The “immediate” flag is about whether the service is actually running properly or not, i.e. if the message can be delivered NOW, rather than being queued for later. This lets apps do things like “send to service A, and if that’s busy, send to service B instead”.

In both cases to make any use of these flags you have to handle returned messages, as you said. The difference between the two options is subtle, and most apps will just say “mandatory & immediate” if they want either.

 

 

RabbitMQ官网解释：

Can you explain how the mandatory flag affects message routing?

From the AMQP specification: "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 manadatory had not been set under the same circumstances the server would silently drop the message."

Can you explain how the immediate flag affects message routing?

From the AMQP specification: "This flag tells the server how to react if the message cannot be routed to a queue consumer immediately". The languange here is a little ambiguous but, to the best of our understanding (and this is what RabbitMQ implements), we take it to mean the following.

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

FWIW, a consumer in this instance is a channel that has used basic.consume to subscribe to a queue (basic.get doesn't qualify a channel as a consumer for these purposes as it is 'instananeous')."