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