<div dir="ltr">Here is a possible non-code solution, network bond your server to server link with a dose of multihoming end-points would deal with some of this. <div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 11:18 AM, Darach Ennis <span dir="ltr"><<a href="mailto:darach@gmail.com" target="_blank">darach@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi guys,<div><br></div><div>To my knowledge there is no obvious way to tune the sensitivity of the failover</div><div>detector in distributed erlang or replace the strategy used to determine when a</div><div>node is considered down with distributed erlang, and hence when a takeover</div><div>may occur or should not occur.</div><div><br></div><div>If the strategy is based on timeouts then something as innocuous as a page</div><div>fault could trigger a transparent huge page fault which in turn will trigger a</div><div>synchronous compaction, all becuase of a little GC or memory churn in</div><div>your IO intensive application. That can manifest as a timeout, which it seems</div><div>could hit you as a distributed erlang netsplit.</div><div><br></div><div>You could turn off transparent huge pages. But netsplit detection is as good</div><div>as the failure detection strategy, the tuning and the qualify of the environment</div><div>its running in... So your mileage will vary.</div><div><br></div><div>You can argue successfully many things at this point:</div><div>* A timeout occurred, its a netsplit, deal with it</div><div>  -> Hanging by a longer rope is still hanging...</div><div>* The timeout is set too keen, widen it and try to avoid THP induced issues by disabling it.</div><div>  -> Cures the cold of a man condemned to death by hanging</div><div>* The failure detector is broken.</div><div>  -> Can't tune it. Can't replace it. We have a problem.</div><div><br></div><div>So, Akash has a very valid concern.</div><div><br></div><div>Perhaps one of the gen_leader revival projects would work well here:</div><div><br></div><div><a href="https://github.com/KirinDave/gen_leader_revival" target="_blank">https://github.com/KirinDave/gen_leader_revival</a><br></div><div><br></div><div>Or even riak_core if a masterless strategy is preferential:</div><div><br></div><div><a href="https://github.com/basho/riak_core" target="_blank">https://github.com/basho/riak_core</a><br><br></div><div>If you need active/active hot/hot or hot/warm or active/passive hot/cold standby then variations on the OpenCall SS7</div><div>Fault Tolerance Controller has been my starting point for HA pairs for years (careful to avoid the patented bits):</div><div><br></div><div><a href="http://www.hpl.hp.com/hpjournal/97aug/aug97a8.pdf" target="_blank">http://www.hpl.hp.com/hpjournal/97aug/aug97a8.pdf</a><br></div><div><br></div><div>Recent adaptive failure detectors such as phi-accrual in akka clustering:</div><div><br></div><div><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:13px"><a href="http://ddg.jaist.ac.jp/pub/HDY+04.pdf" target="_blank">http://ddg.jaist.ac.jp/pub/HDY+04.pdf</a></span><br></div><div><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:13px"><br></span></div><div><font color="#000000" face="Arial, sans-serif"><a href="http://letitcrash.com/post/43480488964/the-new-cluster-metrics-aware-adaptive-load-balancing" target="_blank">http://letitcrash.com/post/43480488964/the-new-cluster-metrics-aware-adaptive-load-balancing</a></font><br></div><div><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:13px"><br></span></div><div>In a nutshell, you don't need to live with bad (not tunable) or badly tuned failure detectors.</div><div><br></div><div>But, unfortunately, you won't find a perfect fit. There isn't any. HA is simply hard. And even</div><div>carrier grade and battle hardened algorithms such as SS7 need considerable tuning to work</div><div>well in a real environment.</div><div><br></div><div>Back to Akash's original issue. I would have concerns with using distributed erlang</div><div>in a production setting. On the one hand, the failover/takeover model is simple and</div><div>attractive. The fact that TCP can be swapped out for another transport in ERTS to</div><div>drive distributed erlang differently... well that seems like a lot of work for plugging in</div><div>an alternate failure detector...</div><div><br></div><div>Cheers,</div><div><br></div><div>Darach.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 7:48 AM, Graham Hay <span dir="ltr"><<a href="mailto:grahamrhay@gmail.com" target="_blank">grahamrhay@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="http://kellabyte.com/2013/11/04/the-network-partitions-are-rare-fallacy/" target="_blank">http://kellabyte.com/2013/11/04/the-network-partitions-are-rare-fallacy/</a><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 10 October 2014 06:52, Dmitry Kolesnikov <span dir="ltr"><<a href="mailto:dmkolesnikov@gmail.com" target="_blank">dmkolesnikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Hello,</div><div><br></div><div>The error message explicitly says that  Erlang distribution experience network split. There might be many reasons for that. Hard to say w/o knowing your env. <br><br>Best Regards,<div>Dmitry >-|-|-(*></div><div><br></div></div><div><div><div><br>On 10.10.2014, at 5.28, Akash Chowdhury <<a href="mailto:achowdhury918@gmail.com" target="_blank">achowdhury918@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I am using failover/takeover feature of distributed erlang. I have primary and secondary node in a group. Most of the times, my app is running on the primary node and secondary node is in-active. But sometimes, I am seeing that my app is running on both nodes simultaneously which is not expected behavior. I know this can happen when there is a netsplit (network disconnection) between two nodes. But that didn't happen in my case. From system stats, it was confirmed that network connection was intact. What can be other causes for this? I see the following error message in primary node log when this issue happened :<br> <br><em>=ERROR REPORT==== ...</em>>>><i> ** Node<secondary node>  not responding **</i>>>><i> ** Removing (timedout) connection **</i>>>><i></i><br><em></em> <br>Any information/help regarding this will be highly appreciated.<br><br>Thanks.<br></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>erlang-questions mailing list</span><br><span><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a></span><br><span><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></span><br></div></blockquote></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></blockquote></div><br></div>
</div></div><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></blockquote></div><br></div>