<div dir="ltr">Hi,<div><br></div><div>I've faced similar problems in the past although on a much more fine grained scale (tens of thousands of these processes, but less important). It was also important to never have overlapping processes. In your case it sounds like you could well live with having two applications running for some time.</div>

<div><br></div><div>We ended up using a distributed consistent locking system. The way it works is that any number of processes tries to grab a named lock and only one process acquire the lock. The lock gives you a lease for a period of time and you have to extend the lease before it expires. If the process or node owning the lock dies and does not clean up after itself, the lock will be released shortly. This works well for very fine-grained locks. Our implementation is released under the MIT license and is on <a href="https://github.com/wooga/locker" target="_blank">https://github.com/wooga/locker</a> Some more highlights: nodes can be added and removed to the cluster dynamically, you can have replicas for scaling reads. I will be presenting it at the Erlang Factory in San Francisco in March. Disclaimer: it makes some really tough trade offs, for example cluster reconfiguration assumes all nodes and the network are behaving well.</div>

<div><br></div><div>As you only have one big thing you want to move around a cluster, it sounds more like you would want to elect a leader among your nodes. When the leader dies (application is shut down or node goes away or it stops checking in with the other nodes), you can elect a new leader and start the application there. gen_leader could help you with this, although I've never used it myself. Zookeper is a good option, but maybe overkill for just a smaller piece of your overall app.</div>

<div><br></div><div>If you can live with multiple instances of your app running, it makes things much more relaxed in terms of consistency. Maybe you could have a look at how Riak is gossiping around the ring. It's relatively simple, decentralized and robust. It could serve as an inspiration.</div>
<div><br></div><div style>Knut</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 7:13 PM, Motiejus Jakštys <span dir="ltr"><<a href="mailto:desired.mta@gmail.com" target="_blank">desired.mta@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
we are about to investigate dynamic node reconfiguration of<br>
distributed applications. Did somebody do that already? How does<br>
kernel application react to application:set_env(kernel, ...)? Or is<br>
there a more elegant approach? We have a quite dynamic cluster of<br>
nodes, and we need one application running all the time. We have our<br>
own solution which is quite simple, but it *seems* like it should be<br>
better done in OTP way.<br>
<br>
Reason: we have a "cluster manager" application, which collects the<br>
cluster health status: started applications, requests per second,<br>
various tests, etc. This information is updated every second via many<br>
rpc calls to all the nodes.<br>
<br>
It would be possible to have the same application running on all the<br>
nodes, but then they all have the same information. Which is data<br>
duplication. Not too many messages, but why repeat ourselves?<br>
<br>
How do/would you approach this "cluster health" problem?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Motiejus Jakštys<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>
</font></span></blockquote></div><br></div>