[Chi Erlang Users] Sharing child processes across supervisors

[Garrett Smith]

I ended up just linking across the servers. Using GAS would change the
way I'm configuring the apps, which is a bit more than I want to
tackle at this point.

Thanks for the pointer though - the dynamic assembly of apps using
file based configs is pretty dang interesting!

On Fri, Mar 5, 2010 at 4:42 PM, Martin Logan <martinjlogan@REDACTED> wrote:
> Ahh, BTW I forgot that you would want to register this gen server and
> link to it from the other processes that care.  I would put the
> linking API into the API of the gen server in question.
>
> On Fri, Mar 5, 2010 at 4:13 PM, Martin Logan <martinjlogan@REDACTED> wrote:
>> I have used a number of things for this.  The thing I use the most is
>> the GAS (General Application Servies) applications ability to
>> configure in such dependencies via the .config file. This gets around
>> the "singleton problem". Basically you would add the gas application
>> as a dependency and then add into your config something like this:
>>
>> {gas,
>>  [
>>   {mod_specs, [{my_service_key, {my_service, start_link, [false]}}]}
>>  ]
>>  },
>>
>> This type of dynamic supervision and its configuration can get much
>> more complex than the most basic example I just provided.  Docs can be
>> found here on the Erlware site:
>> http://erlware.org/lib/5.7.1/gas-8.0.2/index.html
>>
>> Cheers,
>> Martin
>>
>> On Fri, Mar 5, 2010 at 4:04 PM, Garrett Smith <g@REDACTED> 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
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Chicago Erlang User Group" group.
>>> To post to this group, send email to ceug@REDACTED
>>> To unsubscribe from this group, send email to ceug+unsubscribe@REDACTED
>>> For more options, visit this group at http://groups.google.com/group/ceug?hl=en.
>>>
>>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Chicago Erlang User Group" group.
> To post to this group, send email to ceug@REDACTED
> To unsubscribe from this group, send email to ceug+unsubscribe@REDACTED
> For more options, visit this group at http://groups.google.com/group/ceug?hl=en.
>
>