EEP proposal - Delayed restarts of supervisor children

[Loïc Hoguin]

I don't think having optional delays in the supervisor means that it's a 
good match for all use cases.

I do not think supervisor delays are a good match for what we may call 
"network services", be it an interface to a database, an HTTP client, or 
any other process that provides an interface to something external that 
sits across the network.

I do not think jitter or backoff would be a good addition to the supervisor.

But there are cases where delays help in restarts. For example you have 
run out of some kind of resources and restarting immediately is unlikely 
to improve the situation.

Or the process relies on the distribution being up to function and it 
restarts much faster than the distribution restores itself.

It could even be useful in some kinds of "network services". For example 
you might send events via HTTP and it's not a big deal if the events 
make it to the other endpoint or not, just fire and forget. The process 
is up? Great, send it. Otherwise ignore.

Cheers,

On 17/06/2021 15:11, José Valim wrote:
> 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 <mailto: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 <mailto:eeps@REDACTED>
>     http://erlang.org/mailman/listinfo/eeps
> 
> 
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
> 

-- 
Loïc Hoguin
https://ninenines.eu