<div dir="ltr">We're out of CAP world anyway (see my second sentence in that paragraph) so all bets are off.<div><br><div>It's more consistent for it to have a single behavior in the event of a cluster membership change (master/slave failover/takeover), rather than to have two separate behaviors (master/slave failover/takeover on node loss, or master/master split-brain on netsplit).  So that would be "better" and easier to design against.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 1:52 PM, Raoul Duke <span dir="ltr"><<a href="mailto:raould@gmail.com" target="_blank">raould@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Nov 18, 2014 at 1:38 PM, Felix Gallo <<a href="mailto:felixgallo@gmail.com">felixgallo@gmail.com</a>> wrote:<br>
> It's possible that the takeover logic wasn't implemented on network<br>
> partition heal because there's no obviously right thing to do in the generic<br>
> case when two nodes believing themselves to be masters in a distributed<br>
> system discover that they have independently been making progress owing to a<br>
> network partition.  On the other hand, the master/slave system creates data<br>
> loss anyway on node failure.  So I would personally call what you have found<br>
> a bug, and try to make a minimum example case and see if anyone from OTP is<br>
> paying attention.<br>
<br>
<br>
</span>how is it a bug when, "there's no obviously right thing to do"? (not<br>
snarky, just confused/curious/clueless.)<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>