[rabbitmq-discuss] Erlang client rabbit_channel:wait_for_confirms and nacks

Mon Nov 11 16:24:21 GMT 2013

On 11 November 2013 15:43, Simon MacMullen <simon at rabbitmq.com> wrote:
> The expectation is that nacks will be vanishingly rare. To be honest I think
> we never should have added the possibility of sending a nack in confirm
> mode; it can only happen if there is an internal error in the queue. I would
> rather just have the publishing channel die with internal_error at that
> point too.

It makes some sense to have non-fatal nacks if you are relaying; you
can in principle resend or nack upstream. But probably not if the nack
is an indication of something more catastrophic than a message going
astray. (I can imagine it being used for fined-grained flow control,
on some other worldline)

> But if you do want to handle nacks separately you'll need to register a
> confirm handler instead. You could still use wait_for_confirms() to handle
> acks, and then in your confirm handler drop acks and handle nacks.

In the presence of wait_for_confirms_or_die, it seems not only
redundant, but dangerous since it masks errors. Unless you don't care
whether your messages arrive or not, in which case, why use
confirmations ..

> On 11/11/2013 3:25PM, Michael Bridgen wrote:
>>
>> rabbit_channel:wait_for_confirms_or_die/1 and /2 block the process
>> until either all messages sent since the last wait_* call have been
>> acked, or a nack is received in which case exit is called. Is there
>> any way to determine which message or messages were nacked? That might
>> be important.
>>
>> Similarly, rabbit_channel:wait_for_confirms/1 and /2 block the process
>> until acks or nacks for all messages published since the last wait_*
>> was called. I wonder what use are they, if they don't discriminate
>> between acks and nacks?
>>
>> Cheers,
>> Michael
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal