<div dir="ltr">It's possible that the takeover logic wasn't implemented on network partition heal because there's no obviously right thing to do in the generic case when two nodes believing themselves to be masters in a distributed system discover that they have independently been making progress owing to a network partition.  On the other hand, the master/slave system creates data loss anyway on node failure.  So I would personally call what you have found a bug, and try to make a minimum example case and see if anyone from OTP is paying attention.<div><br></div><div>Pragmatically if relatively hackily, it would be a few hours' work to implement a watchdog gen_server that calls nodes(), and on any changes, broadcasts info messages to all affected parties for appropriate resolution.  You could even try to deal with reconciliation between a slave and a master in that scenario if you wanted to be extra clever.</div><div><div><div><div><div><br></div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 1:23 PM, Karolis Petrauskas <span dir="ltr"><<a href="mailto:k.petrauskas@gmail.com" target="_blank">k.petrauskas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have read LYSE and its section on distributed applications in<br>
particular. I have configured my nodes so, that I can determine, which<br>
node is more important than other. The problem is how to stop the<br>
application on the less important node. This problem only occurs after<br>
recovery from netsplit. Ferd's page<br>
(<a href="http://learnyousomeerlang.com/distributed-otp-applications" target="_blank">http://learnyousomeerlang.com/distributed-otp-applications</a>) covers<br>
netsplits only by the following note:<br>
<br>
Note: In terms of distributed programming fallacies, distributed OTP<br>
applications assume that when there is a failure, it is likely due to<br>
a hardware failure, and not a netsplit. If you deem netsplits more<br>
likely than hardware failures, then you have to be aware of the<br>
possibility that the application is running both as a backup and main<br>
one, and that funny things could happen when the network issue is<br>
resolved. Maybe distributed OTP applications aren't the right<br>
mechanism for you in these cases.<br>
<br>
Now I have those "funny things".<br>
<span class="HOEnZb"><font color="#888888"><br>
Karolis<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Nov 18, 2014 at 11:04 PM, Felix Gallo <<a href="mailto:felixgallo@gmail.com">felixgallo@gmail.com</a>> wrote:<br>
> No, it's a specific question having to do with the failover/takeover<br>
> mechanisms.<br>
><br>
> If I'm understanding the problem correctly, ferd's page on the topic may be<br>
> handy -- specifically the bottom part talks about how to configure different<br>
> nodes to recognize themselves as being less important than others.<br>
><br>
> <a href="http://learnyousomeerlang.com/distributed-otp-applications" target="_blank">http://learnyousomeerlang.com/distributed-otp-applications</a><br>
><br>
> On Tue, Nov 18, 2014 at 1:00 PM, Raoul Duke <<a href="mailto:raould@gmail.com">raould@gmail.com</a>> wrote:<br>
>><br>
>> hello? isn't this like a canonical systems engineer question?!<br>
>><br>
>><br>
>> <a href="https://www.google.com/search?q=split+brain+interview+question+networking+storage" target="_blank">https://www.google.com/search?q=split+brain+interview+question+networking+storage</a><br>
>> _______________________________________________<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>
><br>
><br>
><br>
> _______________________________________________<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>
><br>
</div></div></blockquote></div><br></div>