[erlang-questions] simple_one_for_one being unjustly supervised?

[Essien Essien]

Hi Ulf,

Appreciate your time!!

On Sun, Apr 4, 2010 at 11:48 AM, Ulf Wiger
<ulf.wiger@REDACTED> wrote:
>
> The relevant code in the application controller (since I
> happened to have it open, as I snipped from it earlier today)
> is in application_master.erl:
>
> loop_it(Parent, Child, Mod, AppState) ->
>    receive
>        {Parent, get_child} ->
>            Parent ! {self(), Child, Mod},
>            loop_it(Parent, Child, Mod, AppState);
>        {Parent, terminate} ->
>            NewAppState = prep_stop(Mod, AppState),
>            exit(Child, shutdown),
>            receive
>                {'EXIT', Child, _} -> ok
>            end,
>            catch Mod:stop(NewAppState),
>            exit(normal);
>
> As you can see, the supervisor is terminated using exit(Child,shutdown).
> (Child is the pid returned from Mod:start/2).

Yup... looks fine to me too.

>
> I have not looked at your logs, nor do I have a good explanation
> for the discrepancy you're observing.

It has suprised me as well, though I think I've never really been
interested in how children of a simple_one_for_one cleanup in previous
use cases. Right now though, I'm using them for load balancing, so its
important how they cleanup, which is why I've taken an interest and
noticed them now.

I'll try to dig deeper and see if I can at least understand why it is happening.

cheers,
Essien

>
> BR,
> Ulf W
>
>
> Essien Essien wrote:
>>
>> Hi all,
>>
>> Maybe I'm missing something pretty obvious, but I'm noticing that the
>> children of a simple_one_for_one supervisor are being killed off
>> without honoring their "shutdown" interval, when they're taken down by
>> a top-level application. Everything work fine if I sent an
>> exit(SupPid, shutdown) to the top-level supervisor PID though.
>>
>> I have attached a contrived example application called "boss"...
>>
>> The application callback and top-level supervisor behaviours are
>> implemented in the same module.
>>
>> The boss supervisor is a one_for_one supervisor which supervises a
>> "nanny", "manage" and "delay" modules.
>>
>> "nanny" is a simple_one_for_one supervisor which supervises "children"
>> (a gen_server).
>>
>> "manage" is a gen_server which spins up the children by calling
>> nanny:start_child when it starts up. The number of children is read
>> from the boss.app file.
>>
>> "delay" is a gen_server which just delays for a configurable amount of
>> time before shutting down.
>>
>> "children" is a simple gen_server which delays for 5 seconds before
>> shutting down.
>>
>> From my tests in an erl session, if i do:
>>
>> 1 > {ok, Pid} = boss:start_link([8, 5000]). %these arguments mean, 8
>> children, 5 seconds delay for the delay gen_server
>>
>> And then:
>>
>> 2 > exit(Pid, shutdown).
>>
>> Everything happens nicely. I see _all_ my logging messages which
>> suggests that things cleaned up nice and sweet.
>>
>> But if I do:
>>
>> 3 > application:start(boss).
>> 4 > application:stop(boss).
>>
>> ONLY the "delay" module cleans up nicely... I never get to see the
>> logs from the "children" instances... which means the tree just kills
>> them off very fast.
>>
>>
>> Is this a known behaviour? Am I missing something critical?
>>
>> Any wisdoms will be much appreciated.
>>
>> Also, I tried peeking at the code for supervisor.erl (went all the way
>> to do_terminate/2 and shutdown/2) and nothing looks amiss, the code
>> for application_controller.erl would take a bit more than a cursory
>> glance to trace through all that is happening, so I wanted to ask here
>> first, before going any further.
>>
>> cheers,
>> Essien
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>
> --
> Ulf Wiger
> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
> http://www.erlang-solutions.com
> ---------------------------------------------------
>
> ---------------------------------------------------
>
> WE'VE CHANGED NAMES!
>
> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG
> SOLUTIONS LTD.
>
> www.erlang-solutions.com
>
>