<div dir="ltr">Hi Michael,<div><br></div><div>Thanks for your fast reply.</div><div><br></div><div>To be honest, I don't mind that when a node goes down in a RabbitMQ cluster it takes a minute or more to decide that the cluster is broken and what to do. What I don't fully understand is why the node fallen stops confirming for a while, then suddenly resumes for some seconds (not always, just some times) and then stops Rabbit process closing the connection and having confirmed messages lost.</div>

<div><br></div><div>It's my understanding that the node should do something like, I cannot see nodes 1 and 2 (connection is broken), I'm by myself here so I cannot confirm your publishes. Then says I've got to stop, because I'm in minority. However, the fact that is confirming messages for a small lapse of time feels like something is not completely working. Also this actually doesn't always happens, sometimes it does it right, so it's not consistent.</div>

<div><br></div><div>To be honest, i like the trick of having a local RabbitMQ, however for us it would be simpler just a cluster. Having a local RabbitMQ, maintaing some federation or shoveling would be a little overkill.</div>

<div><br></div><div>While doing all these tests. Once, when flushing iptables in node3 it has core dumped some Erlang trace. All times before it simply detects network and rejoins cluster without issues. is this something i should report? how?</div>

<div><br></div><div>Thanks, cheers</div><div>Miguel</div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-04 10:17 GMT+02:00 Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 4 June 2014 at 11:58:41, Miguel Araujo Pérez (<a href="mailto:miguel.araujo.perez@gmail.com">miguel.araujo.perez@gmail.com</a>) wrote:<br>
> > The issue is that sometimes after a while publisher3 resumes<br>
> and continues pushing messages and according to the library<br>
> receiving acks for them, that goes for a period of 6-8 seconds<br>
> until an exception is raised because connection is closed (node3<br>
> stops Rabbit). Those "acked messages" aren't however in the<br>
> queue when I consume it later to see what's inside. However, other<br>
> times it works as i would expect and doesn't enqueue any other<br>
> message after iptables takes place.<br>
><br>
> So I thought this could be a library issue, and ported the code<br>
> to PHP using official php-amqplib and exact same thing happens.<br>
> My theory is that sometimes node3 after trying to coordinate<br>
> with other 2 nodes goes into a partition for some seconds, in those<br>
> seconds it confirms messages and then pause minority cluster<br>
> policy kicks in and stops Rabbit.<br>
<br>
Yes, it takes time for both RabbitMQ and client libraries to detect<br>
connection failure. This is in part due to how TCP works. You can configure<br>
the interval of inactivity for RabbitMQ nodes:<br>
<br>
<a href="https://www.rabbitmq.com/nettick.html" target="_blank">https://www.rabbitmq.com/nettick.html</a><br>
<br>
and use a low (say, 1-3 seconds) heartbeat interval for client libraries.<br>
This should make the exception be thrown much earlier (given that your client<br>
supports it; Pika should) at the cost of having increased network traffic:<br>
<br>
<a href="http://www.rabbitmq.com/reliability.html" target="_blank">http://www.rabbitmq.com/reliability.html</a><br>
<br>
Beyond that, your apps can publish last N messages (excessively) after a network<br>
failure. If your consumers can de-duplicate them (e.g. every message has an id you can set),<br>
that should work well.<br>
<br>
If that's not the case, there is a trick that some companies do: they run a RabbitMQ<br>
node local to machine (which at least greatly reduces the probability of RabbitMQ becoming<br>
unreachable), publish with publisher confirms and a low heartbeat interval to the local<br>
node and use Federation [1] or Shovel [2] to connect that node to other nodes.<br>
<br>
By the way, there are only two official clients: Java and .NET.<br>
<br>
1. <a href="http://www.rabbitmq.com/federation.html" target="_blank">http://www.rabbitmq.com/federation.html</a><br>
2. <a href="http://www.rabbitmq.com/shovel.html" target="_blank">http://www.rabbitmq.com/shovel.html</a><br>
--<br>
MK<br>
<br>
Software Engineer, Pivotal/RabbitMQ<br>
</blockquote></div><br></div></div></div>