[rabbitmq-discuss] Problem with publish confirms
ryankbrown at gmail.com
Mon Apr 7 19:49:59 BST 2014
Thank you Simon. Now I think I have my head wrapped around this whole thing.
On Mon, Apr 7, 2014 at 11:25 AM, Simon MacMullen <simon at rabbitmq.com> wrote:
> On 07/04/2014 18:07, Ryan Brown wrote:
>> However, that said, I am curious about the option of just using
>> amqp_channel:wait_for___confirms/1. I did not use this option for a
>> couple of reasons.
>> First was the fact that using the registered handler is mentioned quite
>> often as the preferred option. My understanding was that using the
>> amqp_channel:wait_for___confirms would cause the channel to wait for a
>> response before another message could be published on that channel. If
>> this is true, it seems like it could slow-down publishing more than
>> registering a handler and letting publishing continue. Is this correct?
>> Or am I misunderstanding the whole workflow?
> It's possible I misunderstood you. I thought you were waiting for the
> confirm - i.e. you were effectively reimplementing wait_for_confirms()
> anyway. Yes, it is slower to call wait_for_confirms() (especially if you
> call it frequently) as you will stop publishing.
> Speaking of misunderstandings; the second reason I did not use
>> wait_for_confirms was that I didn't completely understand the definition:
>> "Wait until all messages published since the last call have been either
>> ack'd or nack'd by the broker; or until timeout elapses."
>> What exactly does it mean by the "last call"?
> The last call to wait_for_confirms().
> This sounded to me as if
>> it may get in a situation that if calls are coming-in rapidly enough
>> that they are publishing new messages prior to the previous message
>> getting ack'd, it would not respond until all such queued messages were
> Yes, that's correct.
> Cheers, Simon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss