Bumping the thread in hope that someone will answer. 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

that's the easiest way.

<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

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

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

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

the whole VM.

<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

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

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

right now to check.

<br>

<br>It seems to happen after a gen_leader process crashes somehow (some internal

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

callback?

<br>

<br>

Thanks in advance.

<br clear="all"><br>-- <br>Best regards,<br>Vasily Sulatskov<br>

</div>

</blockquote>