<div dir="ltr"><div>Hi Matthias, Michael,</div><div><br></div><div>Interesting scenario - thanks for bringing it up. I'd like to address this, but I'm not sure that there's an easy way to do it with the current amqp-client API. Unlike Bunny's VersionedDeliveryTag which Michael pointed out, the amqp-client API doesn't have a data structure that associates a delivery tag with the channel its message was consumed through. We could cache delivery tags for channels internally, but I'm hesitant to go down that road.</div>
<div><br></div><div>While Lyra certainly makes it easier for this scenario to pop up, rare as it might be, the same problem could occur without Lyra when swapping a consumer over to a new channel after the consumer is unexpectedly cancelled and/or the channel is unexpectedly closed. That said, no good solutions come to mind just yet. Do you have any ideas?</div>
<div><br></div><div>Cheers,</div><div>Jonathan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 3:45 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jonathan,<div class="im"><br>
<br>
On 24/10/13 04:14, Jonathan Halterman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lyra distinguishes between recovery and retries. If an invocation<br>
such as Channel.basicConsume fails due to an unexpected (not user<br>
initiated) channel closure, the channel is automatically recovered,<br>
along with any consumers, according to the configured recovery policy.<br>
</blockquote>
<br></div>
one of the trickier aspects of implementing transparent recovery of AMQP channels/connections is what to do about acks for messages received on a previous incarnation of a channel. E.g. say a client has set up a consumer and the server has sent a bunch of messages to the client. Then some event - e.g. a 'publish' to an unknown exchange - occurs that causes the server to close the channel with an error. Now, say the recovery logic is transparently creating a new channel. Concurrently though, the consumer code is still happily processing the messages it received before the error, and attempting to ack them.<br>
<br>
If these acks go to the replacement channel, one of the following will happen:<br>
a) a 'precondition_failed' error is raised by the server, complaining about an unknown delivery tag, or<br>
b) the wrong message is acknowledged, i.e. a message sent on the replacement channel which happens to have the same delivery tag as the messsage sent on the original channel<br>
<br>
How does Lyra deal with this scenario?<br>
<br>
One way to handle this is to simply discard these acks. But that requires the client/app to hold extra state, so it can identify them.<br>
<br>
Regards,<br>
<br>
Matthias.<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>