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

[Simon MacMullen]

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.

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.

Cheers, Simon

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