[rabbitmq-discuss] Publisher confirms requires seperate call to get ack?

Ryan Brown ryankbrown at gmail.com
Tue Jan 7 17:56:04 GMT 2014

I apologize for the silence. I've had an end-of-year rush and vacation. I'm
not picking this up and very much appreciate the great information.

So, question (hopefully responding to this old post is ok). When I receive
a basic.ack, does that confirm that the message has been written to disk?
Or is that just an ack that one of the rabbit nodes has accepted the
publish? My SLA requires the former. One of my coworkers recalled seeing
something that indicated a separate call to confirm the write to disk. (I
am having a hard time finding that article at the moment.)


On Wed, Dec 18, 2013 at 3:00 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 18/12/2013 05:53, Michael Klishin wrote:
>> It depends on your client library. E.g. in Java, C# and Ruby (Bunny) you
>> can publish as many messages
>> as you want and then use Channel#waitForConfirms to wait for all
>> outstanding confirms to arrive.
> You can do so in the Erlang client - either call amqp_channel:wait_for_confirms/1
> every so often or (better) call amqp_channel:register_conform_handler/2
> and accept the confirms yourself. That's better because every time you call
> amqp_channel:wait_for_confirms/1 the channel comes to a halt until all
> confirms have arrived.
>  it doesn't have to be done per message and RabbitMQ pushes confirms to
>> you, you do not poll for acknowledgements.
> This is the key point. It sounds like the OP is publishing one message,
> waiting for one confirm, publishing the next message, and so on. That's an
> antipattern (at least when you want to go fast) since you can never go
> faster than 1 / (network round trip time) messages per second.
> Cheers, Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140107/65967867/attachment.html>

More information about the rabbitmq-discuss mailing list