<div dir="ltr">Hi,<div><br></div><div>Thanks, is there a URL I can access to follow bug status?  </div><div><br></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:14px">> Once a node decides to pause, there may be messages "in flight" that were already</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:14px">

<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:14px">> read from the socket and parsed, and being delivered to queues. These processes</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:14px">

<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:14px">> (in both general and Erlang sense) can run in parallel on machines with over 1 core.</span><br></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:14px"><br>

</span></div><div><font color="#500050" face="arial, sans-serif">My understanding is that for confirming a message, a node in the cluster must see the other nodes and get confirmation from them. If that is the case It makes sense it doesn't confirm messages when iptables rules are applied and that is what happens after some seconds, when it resumes and starts confirming messages that are then lost. </font><span style="color:rgb(80,0,80);font-family:arial,sans-serif">Not sure I follow how multiple cores make things harder here, I'm probably not seeing some concurrent issue here.</span></div>

<div><font color="#500050" face="arial, sans-serif"><br></font></div><div><font color="#500050" face="arial, sans-serif">I'm attaching Erlang log from node3 here. if you look at it you will see how first thing it detects is node rabbitmq-2 and rabbitmq-1 are not responding. Then it promotes mirrored queues from slave to master. Cluster minority status detected comes last thing.</font></div>

<div><font color="#500050" face="arial, sans-serif"><br></font></div><div><font color="#500050" face="arial, sans-serif">I'm not an expert in RabbitMQ internals, I've been reading the code parts that control this flow and it feels like confirms could be paused until being sure things are ok. I mean if node3 knows it's connected to 2 nodes (node2 and node1), then sees both nodes down, looks like something is going wrong. </font></div>

<div><font color="#500050" face="arial, sans-serif"><br></font></div><div><font color="#500050" face="arial, sans-serif">The part that most strikes me is that it takes 1 minute and 3 seconds to detect minority since we know both nodes are down?</font></div>

<div><br></div><div>I will send another email with the Erlang trace.</div><div><br></div><div>Thanks, cheers</div><div>Miguel</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-04 12:57 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 4 June 2014 at 14:55:57, Miguel Araujo Pérez (<a href="mailto:miguel.araujo.perez@gmail.com">miguel.araujo.perez@gmail.com</a>) wrote:<br>


> > While doing all these tests. Once, when flushing iptables in<br>
> node3 it has core dumped some Erlang trace. All times before it<br>
> simply detects network and rejoins cluster without issues.<br>
> is this something i should report? how?<br>
<br>
</div>Miguel,<br>
<br>
We have filed a bug for the general issue here. Feel free to post the trace<br>
you see to the list (unless you think it contains sensitive information, which<br>
is probably doesn't). <br>
<div class=""><div class="h5">--<br>
MK<br>
<br>
Software Engineer, Pivotal/RabbitMQ<br>
</div></div></blockquote></div><br></div></div>