EEP proposal - Delayed restarts of supervisor children

[José Valim]

Thanks Maria and Jan for another EEP!

I have to say, however, that I agree with Fred on this topic. Especially
with the considerations that a restart_delay as an integer value is not
enough. I would even say jitter is more important than backoff in many
cases, and supporting both exponential backoffs and jitter will require
more configuration and more complexity to be added to supervisors, while I
also believe it belongs in the worker, as you gain a lot more flexibility.
As one additional example to what Fred said, what if you want to accumulate
requests while you wait for the connection to be established, and then
issue the commands once it is ready? There are many other considerations
that are only fully realizable in the worker.

On Thu, Jun 17, 2021 at 3:01 PM Maria Scott <maria-12648430@REDACTED>
wrote:

> Hi Viktor :)
>
> > I support this EEP. :-)
>
> Glad to hear :)
>
> > It has been argued before that supervision trees are for fault-tolerance
> > of bugs, not network/external errors. But why not enable the use of
> > supervision subtrees for external faults too?
>
> Yes, I understand both sides of the argument, but yeah, why not? :)
> The real problem we had was to figure out how to delay it right. Dragging
> out the time between crashes and restarts opens up some new scenarios and
> corner cases, especially in the sibling-terminating strategies.
>
> > If we add delays, then how about exponential backoff? e.g. doubling the
> > delay for each failed restart attempt. Is it worth considering too? It
> > has been suggested before and it's common for network re-attempts.
>
> We considered but decided against it, for now at least. Simple as it
> sounds on the surface, there is actually quite some complexity involved. We
> think that providing delays alone is already a big step forward, and paves
> the way to future improvements like incremental delays.
>
> > Just forbid the existence of the key restart_delay when restart type is
> > temporary.
>
> We considered this also, but it feels a bit wrong =^^= I mean, it is
> always allowed to have any meaningless key in the map, they are just
> ignored. Other keys (like significant) are allowed to appear as long as
> their values don't clash with other options. Forbidding some keys to appear
> based on the values of other keys, that would be new and unique.
>
> Regards,
> Maria
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20210617/df240606/attachment.htm>