[rabbitmq-discuss] Consumer Callback

Fri Aug 19 04:22:33 BST 2011

On 19/08/11 00:51, fangbot wrote:
> This makes sense. My goal now is to be able to send both persistent AND
> non-persistent messages to a single consumer. In this case, I want to turn
> auto-acknowledge off so I can acknowledge the messages after I process them,
> in my code. However, I do not wish to send those acknowledgements if the
> message I receive is a non-persistent message.

It's fine to send a mixture of persistent and non-persistent messages to 
a queue, and subsequently consume them. What you cannot do though is 
choose which messages need acknowledgement - that's solely determined by 
the consumer, i.e. whether it is consuming in ack or no-ack mode.

> 1. what if I just acknowledged ALL messages, including non-persistent
> messages? Will acknowledging non-persistent messages have a
> noticeable performance impact on the throughput speeds?

There is certainly a performance penalty for using acks. It's not 
massive though.

> 2. With auto-ack turned on, will a persistent message get ack'ed upon
> arrival to a queue, or when a QueueingConsumer calls nextDelivery()? In
> other words, if I have a consumer binded to a queue, and a persistent
> message gets sent to that queue but the QueueingConsumer does not call
> nextDelivery(), and I shut down the server, will the message get persisted
> to mnesia?

The auto-ack'ing happens when the message is sent to the consumer, since 
only at that point the queue knows what kind of consumer - ack'ing or 
not - the message is being sent to.

Note though that QueuingConsumer is a client-side construct. It queues 
the messages in the client that it was sent from the server. 
nextDelivery() does not interact with the server; it simply dequeues the 
next message from the client-side queue, or waits for more messages to 
arrive. If consuming in auto-ack mode, all such locally queued messages, 
and all messages "in flight" will be lost when the 
client/connection/server dies or is restarted since, as far as the 
server is concerned, they were auto-ack'ed when they were sent to the 
client and hence are no longer held in the (server) queue.

A clean shutdown of the broker will ensure all persistent messages held 
in queues are stored on disk, including those that have been sent to 
clients and are awaiting acknowledgement (i.e. were sent to consumers in 
'ack' mode).

[minor point of correctness: messages are not stored in mnesia but a 
custom high-performance message store (which does keep its data in files 
in the mnesia directory hierarchy, even though it has nothing to do with 
mnesia)]

Regards,

Matthias.