[erlang-questions] Supervisor post start update of restart intensity and period

[Torben Hoffmann]

Hi Michael,

Before diving into changes to the supervisor module there might be a quicker fix that
can give you what you want.

Say that you have a case where 10 children with a restart intensity of 10 is fine.
So your sup_10 supervisor fits 10 mod_a with that configuration.

Now you create a sup_sup supervisor that supervises your sup_10 supervisors.

Before you start a new mod_a worker you determine if you need to start another sup_10
supervisor. Then you start the mod_a as a child of the appropriate sup_10 supervisor.

It requires a bit of interrogation of the supervision tree under sup_sup (using
which_children/1) before starting. But I would say that it beats forking supervisor.

I haven't done the math to see if this two level solution would give you adequate
control over the restart intensity... something for the interested reader ;-)

Cheers,
Torben

Michael Wright writes:

> Does anyone have any interest, approval or disapproval in respect of the
> idea of adding capability to update the restart intensity of a supervisor
> after start?
>
> Currently the only way to change it after start is by way of a release
> change.
>
> My reason for the proposal is to optimise the case of a simple_one_to_one
> supervisor where:
>
>     1. The likely number of children could vary a lot (perhaps by orders of
> magnitude).
>     2. The children are homogeneous and the criticality of the service they
> collectively provide is shared across all of them.
>     3. The probability of abnormal termination of any one child is
> relatively constant (not lessened or known or expected to be lessened by
> more children being spawned).
>
> So for the case of a simple_one_for_one supervisor with 10 children, a
> restart intensity 10 might be appropriate, but for the same supervisor with
> 10,000 children it might need to be 1,000, or 10,000.
>
> In some cases the likely maximum number of children might be known at
> supervisor start time, but not always, and even then if it varies a lot it
> probably doesn't help.
>
> I can't be certain how in demand this feature would be, but I've realised
> I've needed it before, and compromised by setting the restart intensity
> high to avoid unnecessary tear down of software infrastructure. It's
> obviously not ideal though as it could lead to outage or service
> degradation while a relatively small number of children churn their way to
> an inappropriately large restart intensity.
>
> One could have a dynamic intensity value, {ch_multiple, N} say, making it N
> times the number of children, but I slightly worry someone will later want
> {sqrt_ch_mul_ln_moonphase, U, G, H} and then one may as well allow {M, F,
> A} or add a new callback. However, really I think an API call is probably
> the most sensible way forward:
>
>     supervisor:update_supflags/3    (SupRef, intensity | period, NewValue)
>
> I prefer this to passing a map since the above is more explicit that not
> all the supflags are alterable.
>
> An API call is simple and low impact, and the only disadvantage is it
> offers to do nothing clever, making the callback module perform all the
> management, even if it means calling it every time a new child is spawned.
>
> Michael.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

--
Torben Hoffmann
Architect, basho.com
M: +45 25 14 05 38