[rabbitmq-discuss] [ANNOUNCEMENT] Introducing Lyra: A High Availability RabbitMQ Client
matthias at rabbitmq.com
Wed Oct 30 22:45:59 GMT 2013
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
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.
More information about the rabbitmq-discuss