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

Thu Oct 31 02:49:56 GMT 2013

Hi Matthias, Michael,

Interesting scenario - thanks for bringing it up. I'd like to address this,
but I'm not sure that there's an easy way to do it with the current
amqp-client API. Unlike Bunny's VersionedDeliveryTag which Michael pointed
out, the amqp-client API doesn't have a data structure that associates a
delivery tag with the channel its message was consumed through. We could
cache delivery tags for channels internally, but I'm hesitant to go down
that road.

While Lyra certainly makes it easier for this scenario to pop up, rare as
it might be, the same problem could occur without Lyra when swapping a
consumer over to a new channel after the consumer is unexpectedly cancelled
and/or the channel is unexpectedly closed. That said, no good solutions
come to mind just yet. Do you have any ideas?

Cheers,
Jonathan

On Wed, Oct 30, 2013 at 3:45 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> 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.
>
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131030/856de645/attachment.htm>