No subject
Thu Mar 14 15:04:54 GMT 2013
forever even as channels are recovered, but I don't this is a problem since
all usage of those tags will be through Lyra's proxied channel which will
re-adjust them before sending an ack/nack/reject.
What do you think of this approach?
Cheers,
Jonathan
>
> Matthias.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
--001a1133158ea7aa5504ea29b630
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Matthais,<br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Nov 1, 2013 at 7:05 AM, Matthias Radestock <span d=
ir=3D"ltr"><<a href=3D"mailto:matthias at rabbitmq.com" target=3D"_blank">m=
atthias at rabbitmq.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Jonathan,<div class=3D"im"><br>
<br>
On 31/10/13 18:54, Jonathan Halterman wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
I don't suppose you're open to enhancing the amqp-client API to inc=
lude<br>
something like this? :) One possible change would be the inclusion of a<br>
VersionedDeliveryTag like object in the Envelope along with some<br>
corresponding basic ack/nack/reject(<u></u>VersionedDeliveryTag) methods on=
the<br>
Channel interface. The channel's "version" would just be anot=
her piece<br>
of meta information that the user could specify.<br>
</blockquote>
<br></div>
Such an API extension doesn't really make sense in the existing client.=
Plus, in order to take advantage of it client code would have to change, s=
o you might as well bite the bullet and design a recovery-enabled API that =
wraps the existing API.<div class=3D"im">
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
One other idea - Brett Cameron suggested tracking the last delivery tag<br>
for each channel and dropping any ack/nack/reject requests for delivery<br>
tags greater than that. If a channel is recovered, the last delivery tag<br=
>
for the new channel will most likely be less than any delivery tags for<br>
messages consumed on the previously closed channel. This is obviously<br>
not foolproof, but it's not a bad start.<br>
</blockquote>
<br></div>
That's better than the present situation, I suppose, but doesn't ca=
tch the more dangerous of the two ways things can go wrong, i.e. when the o=
ld delivery tags *are* in range of the new ones then the wrong messages get=
acknowledged.</blockquote>
<div><br></div><div>Another approach suggested by Brett - this one seems pr=
etty sound. Start by tracking the max delivery tag for a channel. If a chan=
nel is closed and recovered, we increment subsequent delivery tags by the m=
ax tag we observed for the previous channel. When the user acks/nacks/rejec=
ts a delivery tag, we decrement by the max tag. If the decremented value is=
<=3D 0, then we know the delivery tag is for a previously closed channe=
l.=A0</div>
<div><br></div><div>From the user's perspective this means delivery tag=
s simply increase forever even as channels are recovered, but I don't t=
his is a problem since all usage of those tags will be through Lyra's p=
roxied channel which will re-adjust them before sending an ack/nack/reject.=
=A0</div>
<div><br></div><div>What do you think of this approach?=A0</div><div><br></=
div><div>Cheers,</div><div>Jonathan=A0</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>
<div class=3D""><div class=3D"h5"><br>
<br>
Matthias.<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href=3D"mailto:rabbitmq-discuss at lists.rabbitmq.com" target=3D"_blank">ra=
bbitmq-discuss at lists.<u></u>rabbitmq.com</a><br>
<a href=3D"https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-dis=
cuss" target=3D"_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/l=
istinfo/<u></u>rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div></div>
--001a1133158ea7aa5504ea29b630--
More information about the rabbitmq-discuss
mailing list