<div dir="ltr">Hi Matthias - Comments below,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 31, 2013 at 12:27 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Jonathan,<div><br>
<br>
On 31/10/13 02:49, Jonathan Halterman wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We could cache delivery tags for channels internally, but I'm<br>
hesitant to go down that road.<br>
</blockquote>
<br></div>
It wouldn't help anyway, since, as a mentioned, the same delivery_tag<br>
can appear on both the old and new incarnation of the channel.<br>
delivery_tags are just counters, starting from 1 on a fresh channel.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
While Lyra certainly makes it easier for this scenario to pop up,<br>
rare as it might be,<br>
</blockquote>
<br></div>
It's not rare at all. You are guaranteed to end up in that scenario<br>
anytime a recovery takes place while a consumer is processing a message.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
the same problem could occur without Lyra when swapping a consumer<br>
over to a new channel after the consumer is unexpectedly cancelled<br>
and/or the channel is unexpectedly closed.<br>
</blockquote>
<br></div>
Absolutely. Don't do that :)<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That said, no good solutions come to mind just yet. Do you have any<br>
ideas?<br>
</blockquote>
<br></div>
The scenario is impossible to address without changing the API. Bunny does that with the VersionedDeliveryTag. The Messaging Patterns libraries we wrote some years ago do it by making ack() take the entire Message data structure, and have that include the channel version. See <a href="http://hg.rabbitmq.com/rabbitmq-java-messagepatterns/file/21df7ca85b96/src/main/java/com/rabbitmq/messagepatterns/unicast/Receiver.java#l19" target="_blank">http://hg.rabbitmq.com/<u></u>rabbitmq-java-messagepatterns/<u></u>file/21df7ca85b96/src/main/<u></u>java/com/rabbitmq/<u></u>messagepatterns/unicast/<u></u>Receiver.java#l19</a></blockquote>
<div><br></div><div>One of my goals for Lyra was to minimize the amount of new APIs and allow users to interact mostly with the amqp-client API while still gaining the benefits of transparent recovery, but it seems like that might not be possible.</div>
<div><br></div><div>The ReceivedMessage approach would work as long as you don't need to store the ReceivedMessage off for later use, something that I imagine is not uncommon. In that case, something like Bunny's <span style="font-family:arial,sans-serif;font-size:13px">VersionedDeliveryTag would work well, tracking the channel version rather than an unserializable reference to the channel itself. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I don't suppose you're open to enhancing the amqp-client API to include something like this? :) One possible change would be the inclusion of a VersionedDeliveryTag like object in the Envelope </span>along with some corresponding basic ack/nack/reject(<span style="font-family:arial,sans-serif;font-size:13px">VersionedDeliveryTag</span>) methods on the Channel interface<span style="font-family:arial,sans-serif;font-size:13px">. The channel's "version" would just be another piece of meta information that the user could specify. </span><span style="font-family:arial,sans-serif;font-size:13px">Short of any amqp-client API changes, I'll have to think about how to best introduce new Lyra APIs to achieve what's needed here while staying out of the way of the existing amqp-client API as much as possible.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>One other idea - Brett Cameron suggested tracking the last delivery tag for each channel and dropping any ack/nack/reject requests for delivery tags greater than that. If a channel is recovered, the last delivery tag for the new channel will most likely be less than any delivery tags for messages consumed on the previously closed channel. This is obviously not foolproof, but it's not a bad start.<span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Cheers,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Jonathan</span></div>
<div><br></div><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><br>
<br>
Regards,<br>
<br>
Matthias.<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></div>