Bumping the thread in hope that someone will answer.<br><br><br>On Tuesday, December 18, 2012 8:32:13 PM UTC+1, Vasily Sulatskov wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">Hi,
<br>
<br>I am using gen_leader from <a href="https://github.com/abecciu/gen_leader_revival" target="_blank">https://github.com/abecciu/<wbr>gen_leader_revival</a> and I
<br>want to use it with a fixed list of candidate nodes - as far as I understand
<br>that's the easiest way.
<br>
<br>I tried several variations of starting gen_leader but none was satisfactory.
<br>
<br>I start it as part of a supervision tree, so all examples are taken from
<br>gen_supervisor modules init/1 functions:
<br>
<br>Here's what I tried so far:
<br>
<br>init(_Args) ->
<br>    %% The same value is used on all machines in the cluster
<br>    Leader_nodes = ['foobar@node1', 'foobar@node2', 'foobar@node3'],
<br>
<br>    Home = os:getenv("HOME"),
<br>
<br>    Gen_leader_config = {gen_leader_module, {gen_leader_module, start_link,
<br>                               [Leader_nodes,
<br>                                [{vardir, Home}]]},
<br>                  permanent, 2000, worker, [gen_leader_module]},
<br>
<br>    {ok, {{one_for_one, 10000, 1},
<br>          [Gen_leader_config]}}.
<br>
<br>If I do this, then nodes specified in Leader_nodes work just fine, they all
<br>participate in elections, leaders are elected properly, they are able to do
<br>gen_leader:leader_call() to the actual leader etc.
<br>
<br>The problem is that on all other nodes (which are not specified in
<br>Leader_nodes) gen_leader is not started at all. Gen_leader checks if the node
<br>it's running on is one of "candidate nodes" or "worker nodes" and if that's not
<br>the case - it simply doesn't start. All further attempts at
<br>gen_leader:leader_call from that node fail.
<br>
<br>I tried to run every node in the cluster except for "candidate nodes" as a
<br>"worker node", so I changed supervisor to something like:
<br>
<br>init(_Args) ->
<br>    %% The same value is used on all machines in the cluster
<br>    Leader_nodes = ['foobar@node1', 'foobar@node2', 'foobar@node3'],
<br>
<br>    Workers =
<br>        case lists:member(node(), Leader_nodes) of
<br>            true ->
<br>                [];
<br>            false ->
<br>                [node()]
<br>        end,
<br>
<br>    Home = os:getenv("HOME"),
<br>
<br>    {ok, {{one_for_one, 10000, 1},
<br>          [{scheduler, {scheduler, start_link,
<br>                               [Leader_nodes,
<br>                                [{vardir, Home},
<br>                                 {workers, Workers}]]},
<br>            permanent, 2000, worker, [scheduler_leader]}]}}.
<br>
<br>As far as I understand, when gen_leader runs in a worker configuration, it
<br>doesn't participate in elections, but still keeps track of where an actual
<br>leader is running, so gen_leader:leader_call is still possible.
<br>
<br>This setup kind of works, but it seems that gen_leader process on "worker" nodes
<br>constantly grows in memory usage, past several Gb at least, eventually crashing
<br>the whole VM.
<br>
<br>Am I running gen_leader correctly?
<br>
<br>What is the correct way of running gen_leader with a fixed set of "candidate"
<br>nodes and that every other node is aware of where a leader is running, so that
<br>gen_leader:leader_call() is possible?
<br>
<br>Which version of gen_leader is recommended to use? This one
<br><a href="https://github.com/abecciu/gen_leader_revival" target="_blank">https://github.com/abecciu/<wbr>gen_leader_revival</a>? Or maybe the version from
<br>gproc? By the way can someone explain what's the difference between them?
<br>
<br>
<br>And I have another, most likely unrelated, issue with gen_leader. On one
<br>deployment, sometimes I find a cluster in a state with two leaders - most of
<br>the nodes think that the leader is one node, but some other node thinks
<br>that the leader is on the other node. I am not sure if the other leader is the
<br>node that diverges from the consensus - I don't have a cluster in this state
<br>right now to check.
<br>
<br>It seems to happen after a gen_leader process crashes somehow (some internal
<br>work, not related to gen_leader magic).
<br>
<br>The other thing that I think might be important here, is that gen_leader
<br>process in that setup can get stuck in handle_leader_call for quite some long
<br>time. Can it cause problems with leader elections? Should gen_leader processes
<br>not block in handle_whatever functions and always be able to handle election
<br>callback?
<br>
<br>
<br>Thanks in advance.
<br clear="all"><br>-- <br>Best regards,<br>Vasily Sulatskov<br>
</div>
</blockquote>