<font face="trebuchet ms,sans-serif">Hi Alexis, I've had to deal with the same situation as Matt describes in the past and in the end the scenarios in case of channel closure were:</font><div><ul><li><font face="'trebuchet ms', sans-serif">discard messages delivered to the consumer but not yet dispatched to the application, assuming they will be redelivered</font></li>
<li><font face="'trebuchet ms', sans-serif">dispatch them to the application and not bother acking them as acking wouldn't obviously succeed</font></li><li><font face="'trebuchet ms', sans-serif">dispatch them to the application and try acking them anyway, catching errors that inevitably will be raised due to the channel being closed</font></li>
</ul><div><font face="'trebuchet ms', sans-serif">Although it's not the cleanest solution I've chosen the third one (assuming a sensible prefect-count value, as swallowing lots of ack errors would likely affect the application performance) for a couple of reasons - quite dependent on the context btw:</font></div>
<div><ul><li><font face="'trebuchet ms', sans-serif">I wanted my application to see the messages the consumer had received as soon as possible, without waiting for them to be eventually redelivered</font></li><li>
<font face="'trebuchet ms', sans-serif">Not treating the scenario in which messages are acked on a closed channel as a special case helped keep simplicity</font></li><li><font face="'trebuchet ms', sans-serif">You have to deal with deduplication anyway compared to option 1 above (which may create the false assumption that you wouldn't have to do so in that case)</font></li>
</ul><div><font face="'trebuchet ms', sans-serif">Simone</font></div></div><div><br><div class="gmail_quote">On Wed, Mar 7, 2012 at 21:25, Alexis Richardson <span dir="ltr"><<a href="mailto:alexis@rabbitmq.com">alexis@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matt<br>
<br>
Could you achieve what you want by lifting 'ack' to the application layer?<br>
<span class="HOEnZb"><font color="#888888"><br>
alexis<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Mar 7, 2012 at 8:20 PM, Simone Busoli <<a href="mailto:simone.busoli@gmail.com">simone.busoli@gmail.com</a>> wrote:<br>
> Hi Matt, your understanding is correct, acknowledgements are meaningful only<br>
> within the context of the same channel, therefore the answer to your last<br>
> question is no.<br>
> If the connection bounces or the channel closes for any other reasons you<br>
> should not acknowledge the messages your consumer was delivered already and<br>
> just assume they will be redelivered to the next consumer which will start<br>
> consuming to the same queue.<br>
><br>
> On Wed, Mar 7, 2012 at 21:00, Matt Pietrek <<a href="mailto:mpietrek@skytap.com">mpietrek@skytap.com</a>> wrote:<br>
>><br>
>> I thought I understood this topic clearly, but some recent experiences<br>
>> have me seeking more info, as I can't find this exact topic explicitly<br>
>> described.<br>
>><br>
>> When a message is delivered on a particular connection/channel<br>
>> combination, can it ever be successfully acknowledged on a different<br>
>> connection?<br>
>><br>
>> My current understanding is "no".<br>
>><br>
>> Some background: In our messaging layer, we want to hide the connection<br>
>> drops from the upper application layer. That is, if we try to use a<br>
>> previously working connection/channel, and it fails, we'll simply catch the<br>
>> exception and try to reconnect.<br>
>><br>
>> So the question is, after the reconnect, should we even attempt to<br>
>> acknowledge messages read from the original connection?<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> rabbitmq-discuss mailing list<br>
>> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> rabbitmq-discuss mailing list<br>
> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
><br>
</div></div></blockquote></div><br></div></div>