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

Fri Nov 1 14:05:46 GMT 2013

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.

Matthias.