[erlang-questions] Supervision question

[David Leach]

Yes you're right, now that I re-read my question it's not particularly relevant.


worker_sup will not be restarted by super_sup if the max restarts for poolboy pool is reached.


A caller will call:

start_pool_link(Opts)

This triggers the super_sup to start a worker_sup which starts poolboy.

The caller is linked to worker_sup, so if it goes down (because it dies or because the max restart is reached) the caller will also go down.

If the caller goes down, the pool_managager which is monitoring the caller will take worker_sup down with exit(WorkerSupPid, shutdown). Resorting to the monitor is because worker_sup won't go down when the caller exits.


This is so that in the situation where either the caller or the pool goes down all processes are cleaned up.


Let me know if you need any further clarification.


________________________________
From: Sean Cribbs <seancribbs@REDACTED>
Sent: Tuesday, 1 December 2015 10:58 a.m.
To: David Leach
Cc: Erlang Questions
Subject: Re: [erlang-questions] Supervision question

If I'm reading this correctly, your worker_sup will be restarted after the max_restarts is reached for the poolboy pool. This means that the caller can link or monitor worker_sup, correct? Or do you need a one_for_all strategy?

I have a suspicion dependencies (link/monitor) and discovery (gproc, registered names) are also being confused or conflated in your question.

On Mon, Nov 30, 2015 at 3:25 PM, David Leach <dleach@REDACTED<mailto:dleach@REDACTED>> wrote:

Hi All,


We have an application that starts pools of different kinds of workers and we want to offer the caller the ability to "link" to a pool of workers. We're using poolboy to manage the pools and gproc for naming the pools and ensuring startup is complete before returning a reference to the caller. We don't want to link to poolboy, because it can and should be restarted by the supervisor supervising it. The behavior we want is, if the supervisor managing poolboy reaches its maximum restarts  the caller who is linked also dies. We also want that pool to disappear if the caller dies and the caller can restart it again. Structure looks a little like this:


                                                   pool_manager

super_sup -> worker_sup ->

                                                   poolboy


Right now, the caller is linked to the worker_sup so that if the worker_sup goes down caller also goes down. The pool_manager monitors the caller and sends exit(WorkerSupPid, shutdown) if the caller goes down so that the pool gets cleaned up.


Is there a better way of doing this? Better being easier for someone reading the code to understand quickly or more reliably if there is a problem with this implementation?


We thought about having the super_sup start two children, one of them performing the role of the pool_manager in this situation . But that seems a bit excessive, and how might one name it clearly to differentiate the roles of the pool_manager and it. The pool manager takes care of details of the pool and translates the reference the caller has to a pid.


Thanks in Advance,


David

_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
http://erlang.org/mailman/listinfo/erlang-questions


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151130/25e56cd2/attachment.htm>