[rabbitmq-discuss] [ANNOUNCEMENT] Introducing Lyra: A High Availability RabbitMQ Client

Sat Nov 2 03:59:45 GMT 2013

Hi Matthais,

On Fri, Nov 1, 2013 at 7:05 AM, Matthias Radestock <matthias at rabbitmq.com>wrote:

> Jonathan,
>
>
> On 31/10/13 18:54, Jonathan Halterman wrote:
>
>> 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 along with some
>> corresponding basic ack/nack/reject(VersionedDeliveryTag) methods on the
>> Channel interface. The channel's "version" would just be another piece
>> of meta information that the user could specify.
>>
>
> 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, so
> you might as well bite the bullet and design a recovery-enabled API that
> wraps the existing API.
>
>
>  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.
>>
>
> That's better than the present situation, I suppose, but doesn't catch the
> more dangerous of the two ways things can go wrong, i.e. when the old
> delivery tags *are* in range of the new ones then the wrong messages get
> acknowledged.

Another approach suggested by Brett - this one seems pretty sound. Start by
tracking the max delivery tag for a channel. If a channel is closed and
recovered, we increment subsequent delivery tags by the max tag we observed
for the previous channel. When the user acks/nacks/rejects a delivery tag,
we decrement by the max tag. If the decremented value is <= 0, then we know
the delivery tag is for a previously closed channel.