Amqp: Basic. Publish immediate versus mandatory

Reprinted: 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 amqpBasic. PublishMethod, 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: MandatoryOption 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: ImmediateOption 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 optionsExchange # publishIn Bunny, youMustCheck 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

TheClient # returned_messageMethod takes an optional: TimeoutArgument (default value is 0.1 seconds). This allows you to specify how long the method will wait to receive a returned message shoshould the default value prove to be problematic.

If there is a returned message the method returns a hash containing: Header,: PayloadAnd: 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 need CT 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.

 

 

Explanation on the official website of rabbitmq:

Can you explain how MandatoryFlag 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 wocould silently drop the message."

Can you explain how ImmediateFlag 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 specified Ange 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 receept 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 'instaneous ')."