[rabbitmq-discuss] 'immediate' vs 'mandatory'

Matthew Sackman matthew at rabbitmq.com
Sun Jun 6 18:36:21 BST 2010

On Sun, Jun 06, 2010 at 10:20:56AM -0700, Oleg Zhurakousky wrote:
> Well, if the only way for the server to know "the client has processed the message successfully is if it receives an ack", but at the same time server can not wait for an ack forever (in case of client failures), then what is the purpose of an ACK in relation to 'immediate' flag? It seem to be meaningless... right? 

Yeah, I wouldn't really disagree with that. You could have some
requirement that you don't want messages to be buffered in the queue,
but, as you don't know the qos settings of any consumer, you have no way
of knowing what buffering the consumers are doing: by default, the
client buffers are unbounded. Furthermore, you have no knowledge of
whether the consumer was consuming with noAck set, in which case the
client really has responsibility for the future of the message, or if
the client is meant to be acking, in which case the server is still
maintaining responsibility.

About the only thing that you can gather from not getting a return when
using immediate is that the queue had an unblocked consumer. Of course,
you don't actually know whether you've not got a return - it may be
awaiting you in the future.


More information about the rabbitmq-discuss mailing list