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

[Matthias Radestock]

Jonathan,

On 24/10/13 04:14, Jonathan Halterman wrote:
> Lyra distinguishes between recovery and retries. If an invocation
> such as Channel.basicConsume fails due to an unexpected (not user
> initiated) channel closure, the channel is automatically recovered,
> along with any consumers, according to the configured recovery policy.

one of the trickier aspects of implementing transparent recovery of AMQP 
channels/connections is what to do about acks for messages received on a 
previous incarnation of a channel. E.g. say a client has set up a 
consumer and the server has sent a bunch of messages to the client. Then 
some event - e.g. a 'publish' to an unknown exchange - occurs that 
causes the server to close the channel with an error. Now, say the 
recovery logic is transparently creating a new channel. Concurrently 
though, the consumer code is still happily processing the messages it 
received before the error, and attempting to ack them.

If these acks go to the replacement channel, one of the following will 
happen:
a) a 'precondition_failed' error is raised by the server, complaining 
about an unknown delivery tag, or
b) the wrong message is acknowledged, i.e. a message sent on the 
replacement channel which happens to have the same delivery tag as the 
messsage sent on the original channel

How does Lyra deal with this scenario?

One way to handle this is to simply discard these acks. But that 
requires the client/app to hold extra state, so it can identify them.

Regards,

Matthias.