[erlang-questions] Sharing child processes across supervisors

Jayson Vantuyl kagato@REDACTED
Fri Mar 5 23:16:09 CET 2010


Have the gen_server link to the other gen_servers (or vice-versa).  Then when one fails, the other dies, and the supervisors in the remote apps take care of it.  It might require some synchronization around the restarting (or maybe a delay in somebody's init), but I've done this sort of thing a lot.

On Mar 5, 2010, at 2:04 PM, Garrett Smith wrote:

> I have a gen_server that maintains a connection to something. I'd like
> to have a single such gen_server per release (VM instance).
> 
> I generally run this server under a one_for_all supervisor -- anyone
> who depends on that connection is also under this supervisor. When the
> connection fails, the dependencies are all restarted.
> 
> If I have multiple OTP applications that share this connection, each
> application will want to supervise the gen_server. I could merge the
> supervisory trees of the multiple applications into one, but this
> doesn't feel right at all - I want to keep the applications as
> separate as possible.
> 
> I'm tempted to modify the start_link of the connection to look like this:
> 
>  start_link() ->
>    case gen_server:start_link({local, ?SERVER}, ?MODULE, [], []) of
>      {ok, Pid} -> {ok, Pid};
>      {already_started, Pid} -> {ok, Pid};
>      Other -> Other
>    end.
> 
> My thinking is that this would fake out supervisors that subsequently
> tried to start the connection, causing them to link and supervisor as
> if they actually started it. Naively, it would seem that a connection
> failure would be detected by all of the linked supervisors, triggering
> the expected cascades. One of the applications would end up restarting
> the connection and the rest would link per the "fake out" above.
> 
> Would this approach be bad for any reason? Is there a better or
> standard way of getting supervision across applications?
> 
> Garrett
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> 

-- 
Jayson Vantuyl
kagato@REDACTED



More information about the erlang-questions mailing list