[openstack-dev] [Openstack] High Available queues in rabbitmq

Eugene Kirpichov ekirpichov at gmail.com
Thu Aug 2 15:02:14 UTC 2012


The review is going on at https://review.openstack.org/#/c/10305/

On Thu, Aug 2, 2012 at 12:31 AM, Daniel He <csdhe.geek at gmail.com> wrote:
> Hi Eugene,
>
> By the way, where is these patches I can download/checkout thanks
>
> Dan
>
> On 1 August 2012 23:01, Eugene Kirpichov <ekirpichov at gmail.com> wrote:
>>
>> Hi Andrea,
>>
>> I think you're right that it's necessary to react to cancel notifications.
>> I'll address this in my patch.
>>
>> On Fri, Jul 27, 2012 at 7:05 AM, Rosa, Andrea (HP Cloud Services)
>> <andrea.rosa at hp.com> wrote:
>> > Hi
>> >
>> >>As for consumer cancellation notifications - I need to remember when
>> >>exactly they happen in an HA setup. Maybe you're right.
>> >
>> > With the HA active/active configuration clients always consume from the
>> > Master node so we can have a scenario where the queue is declared on a Slave
>> > node but the clients are consuming from the Master node.
>> > In this situation if the master node goes down the client doesn't get
>> > any error/exception from the connection and the consumer is abruptly
>> > disconnected, so the client needs to re-consume the queue (register a new
>> > consumer) to be able to get messages from the queue.
>> > The consumer cancellation notifications is a way for a client to get a
>> > notification (via a basic.cancel message) when the consumer has been
>> > disconnected.
>> >
>> > With the HA configuration we should care about of two things:
>> > 1 connection dying : this is already addressed by the existing code
>> > 2 basic.cancel notification received by the clients: in my opinion this
>> > is not yet addressed
>> >
>> >>As for duplicated messages - the situation here is no different
>> >>whether you have 1 or many rabbits; reconnection logic was already in
>> >>place. Perhaps something should be done here, but it seems that the
>> >>lack of this logic didn't hurt anyone so far. Maybe it is because IIRC
>> >>messages are ack'd immediately and the failure window is very small.
>> >
>> > Yes you are absolutely right, but with the HA configuration is more
>> > likely to have retransmissions.
>> > If I have a single rabbit and NOT durable queue, all messages (also
>> > messages not yet ack'ed) in the queues are lost if the node goes down, that
>> > means that when the server restarts there are no messages left and so no
>> > retransmissions.
>> > With multiple rabbits, messages not yet ack'ed are mirrored in the other
>> > queues and in the event of failure of the master those messages will be
>> > retransmitted.
>> >
>> >
>> >>> Is there some plan to have a blueprint for this change?
>> >>I don't have such a plan. Should I?
>> >
>> > I need to deeply investigate and tests the HA Active/Active
>> > configuration, but If I can recreate some "complex" configuration to prove
>> > that we need to deal with the basic.cancel messages maybe it's worth to have
>> > one.
>> >
>> > Regards
>> > --
>> > Andrea Rosa
>> >
>>
>>
>>
>> --
>> Eugene Kirpichov
>> http://www.linkedin.com/in/eugenekirpichov
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Dan He
> -----------------------
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov



More information about the OpenStack-dev mailing list