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

[Michael Wright]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151020/f8be5884/attachment.htm>