Question

I’m a little confused about clustering with gproc as a pubsub.

I would like to hold client sessions with gproc… It works great with one node.

However, I need to cluster the whole system.

It seems (as far as I undertand) that gproc has 2 way working with clusters, setting it as global, or using gproc_dist which seems to be a gen_leader behaviour.

Am I right so far ?
What would be the downside of each method ? (Still assuming I undertood correctly)

Answer 1

1. I think the global is implemented by gen_leader. so they are the same method.

2. the gproc_dist_tests.erl already give the sample code for explanation.

   dist_test_() ->
   {timeout, 120,
    [{setup,
      fun() ->
          Ns = start_slaves([dist_test_n1, dist_test_n2]),
          ?assertMatch({[ok,ok],[]},
               rpc:multicall(Ns, application, set_env,
                     [gproc, gproc_dist, Ns])),
          ?assertMatch({[ok,ok],[]},
               rpc:multicall(Ns, application, start, [gproc])),
          Ns
      end,
      fun(Ns) ->
          [rpc:call(N, init, stop, []) || N <- Ns]
      end,
      fun(Ns) ->
          {inorder,
       [
        {inparallel, [
                  fun() ->
                          ?debugVal(t_simple_reg(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_simple_counter(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_aggr_counter(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_update_counters(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_shared_counter(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_mreg(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_await_reg(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_await_self(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_await_reg_exists(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_give_away(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_sync(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_monitor(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_subscribe(Ns))
                  end
                 ]
        },
        fun() ->
            ?debugVal(t_sync_cand_dies(Ns))
        end,
        {timeout, 90, [fun() ->
                   ?debugVal(t_fail_node(Ns))
               end]}
       ]}
      end
     }]}.
   

3. I think gproc is created for solving the erlang’s process register restriction. That’s “only atom not tuple” can be used as registered key and one and only one process can be registered for one registered key.
   The erlang has already provided mnesia db etc for solving client session data.
   If the client session data throughout is high, I think it is not good idea to use gproc to handle it, for it will delay the process registration.