How does an Erlang gen_server start_link a gen_server on another node?

Question

I have an Erlang application that is getting a little too resource-hungry to stay on one node. I'm in the process of making gen_servers move from one process to another - which turns out to be relatively easy. I'm at the last hurdle: getting the factory process that creates these gen_servers to spawn them on the remote node instead of the local one. The default behavior of start_link is clearly to start locally only, but I don't see any option to change that.

It would seem that I'm going to have to be inventive with the solution and wanted to see if anyone out there had already implemented something like this with any success. IOW, what's the recommended solution?

EDIT

I'm looking at the chain of calls that are triggered by calling:

gen_server:start_link(?Module, Args, [])

gen_server:start_link/3:

start_link(Mod, Args, Options) ->
    gen:start(?MODULE, link, Mod, Args, Options).

gen:start/5:

start(GenMod, LinkP, Mod, Args, Options) ->
    do_spawn(GenMod, LinkP, Mod, Args, Options).

gen:do_spawn/5:

do_spawn(GenMod, link, Mod, Args, Options) ->
    Time = timeout(Options),
    proc_lib:start_link(?MODULE, init_it,
                        [GenMod, self(), self(), Mod, Args, Options], 
                        Time,
                        spawn_opts(Options));

proc_lib:start_link/5:

start_link(M,F,A,Timeout,SpawnOpts) when is_atom(M), is_atom(F), is_list(A) ->
    Pid = ?MODULE:spawn_opt(M, F, A, ensure_link(SpawnOpts)),
    sync_wait(Pid, Timeout).

Which finally gets us to the interesting bit. There is a spawn_opt/4 that matches:

spawn_opt(M, F, A, Opts) when is_atom(M), is_atom(F), is_list(A) ->
    ...
    ...

BUT, there is one that would actually be useful to me:

spawn_opt(Node, M, F, A, Opts) when is_atom(M), is_atom(F), is_list(A) ->
    ...
    ...

It boggles my mind that this isn't exposed. I realize that there is a risk that a careless programmer might try to gen_server:start_link a process on a erlang node that happens to be running on Mars, blocking the call for half an hour, but surely, that's the programmers' lookout. Am I really stuck with modifying OTP or writing some sort of ad-hoc solution?

Answer 1

We don't start_link a server on the remote node directly. For a good program structure and simplicity, we start a separate application on the remote node, and delegate the creation of remote processes to a certain process running in the remote application.

Since linking to a process is mainly for the purpose of supervising or monitoring, we prefer doing the linking with local supervisors instead of remote processes. If you need the aliveness status of any remote process, I recommend erlang:monitor and erlang:demonitor.

A typical distributed set-up:

Node1
+---------------+                          Node2
| App1          |                          +---------------+
|   Supervisor1 |  Proc Creation Request   | App2          |
|     Processes | -----------------------> |   Supervisor2 |
|     ......    |                          |      |
|     ......    |                          |      | Create Children
|     ......    |       Monitor            |      V
|     ......    | -----------------------> |     Processes |
+---------------+                          |     ......    |
                                           +---------------+

Answer 2

Maybe rpc module helps you. Especially function async_call.