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

[Matthias Radestock]

Jonathan,

On 02/11/13 03:59, Jonathan Halterman wrote:
> 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.
> [...]
> What do you think of this approach?

That's a pretty neat idea. I was thinking of using the upper bits of the 
delivery tag to indicate the version, but that uses up the delivery tag 
range too quickly. Brett's idea is much better.

I can see just one problem with it: when an application uses multi-ack 
(http://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.ack.multiple) 
and the delivery_tag is for a new message, then only new messages, not 
old ones, are acked, which may surprise the app when it later on gets 
the same old messages redelivered.

OTOH that really is a more general issue with automatic recovery. 
Without recovery, an application can assume that it will not see a 
message twice on the same channel. With recovery that assumption no 
longer holds. Now, one would hope few apps rely on the former, so I 
reckon as long as this potentially breaking behaviour is documented 
prominently then it's not an issue.

Matthias.