<div dir="ltr">Thanks Simon. One more question:<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">So this is something we've seen before in the case of short-lived partitions; something in Mnesia is sending a stray {mnesia_locker, ..., ...} message to a process that isn't expecting it after the partition, killing the process in question.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Do you have a sense whether this behavior is specific to having Autoheal enabled? In other words, if we didn't have Autoheal in effect, could it still happen?</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 5:08 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 15/04/14 23:09, Matt Pietrek wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is rabbitmq 3.2.4, running in a 2 node cluster with all queues in ha.<br>
</blockquote>
<br>
</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At some point we saw a network partition (see below). It appears that<br>
Autoheal eventually worked, but afterwards the cmcmd queue wasn't on the<br>
broker.<br>
</blockquote>
<br>
</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=ERROR REPORT==== 14-Apr-2014::18:02:30 ===<br>
** Generic server <0.204.0> terminating<br>
** Last message in was {mnesia_locker,rabbit@<u></u>sea5m1mq1,granted}<br>
** When Server state == {state,2,{from,<0.302.0>,#Ref<<u></u>0.0.1372.163190>}}<br>
** Reason for termination ==<br>
** {unexpected_info,{mnesia_<u></u>locker,rabbit@sea5m1mq1,<u></u>granted}}<br>
</blockquote>
<br></div>
So this is something we've seen before in the case of short-lived partitions; something in Mnesia is sending a stray {mnesia_locker, ..., ...} message to a process that isn't expecting it after the partition, killing the process in question.<br>

<br>
The release notes for Erlang 17.0 contain:<br>
<br>
OTP-11497  To prevent a race condition if there is a short communication<br>
           problem when node-down and node-up events are received. They<br>
           are now stored and later checked if the node came up just<br>
           before mnesia flagged the node as down. (Thanks to Jonas<br>
           Falkevik )<br>
<br>
which sounds like the same thing.<br>
<br>
So it is quite possible that this is fixed in Erlang 17.0.<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal<br>
</font></span></blockquote></div><br></div>