[erlang-questions] Gproc in a dynamic cluster

[Ulf Wiger]

On 2 Aug 2011, at 16:32, Mihai Balea wrote:

> 
> On Aug 2, 2011, at 9:08 AM, Ulf Wiger wrote:
> 
>> 
>> On 1 Aug 2011, at 16:00, Ulf Wiger wrote:
>> 
>>> This could all be baked into the 'all' option somehow. I'll think about that.
>> 
>> Turns out that adding the {bcast_type, all} option did the trick.
>> 
>> In the HEAD version of http://github.com/esl/gproc, dynamic addition of nodes seems 
>> to work as expected when you use the option -gproc gproc_dist all.
>> 
>> Let me know if it doesn't work for you.
> 
> Still no automatic workage, but I wasn't really expecting that.

What exactly did you try?

> Is there a way to manually prod gproc into joining another nodes after startup? The way i have it set up, nodes boot with gproc booting in global mode as a top level app. Then nodes find each other using an out of band mechanism and use net_adm:ping to connect. By glancing at gen_leader code, it appears there's no way for gen_leader to automatically be aware of newly connected nodes, so I figure there might be a way to indicate it manually.

What I tried, and what worked for me, was:

- starting node n1 with (-gproc gproc_dist all), and doing application:start(gproc)
- starting node n2 the same way (making sure to first ping n1)
- registering a global resource at n2, verifying that it was replicated to n1
- starting n3
- verifying that the global resource was visible on n3 afterwards

Basically, when a new instance of gproc joins the cluster, the current leader will broadcast an updated candidate list.

Note that the nodes must be connected before starting gproc. Gproc_dist will simply use the nodes() list, so if the nodes haven't connected first, it won't work.

Note also that gen_leader (and thus gproc) has no facility for resolving netsplits. This is a reason why you need to do it this way; otherwise, the procedure can't be easily distinguished from a netsplit.

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com