EEP proposal - Delayed restarts of supervisor children

José Valim jose.valim@REDACTED
Thu Jun 17 18:44:05 CEST 2021


Thanks for the clarification!

I understand that delayed results can't solve all cases. The question is if
the amount of cases they do solve are plenty and if they are an appropriate
solution. I am worried that a limited solution will give a false sense of
security. Say your processes crash because of system overload. Then you add
the delayed restart to give the system some time to recover. Are we sure it
is going to be any effective without back-offs or jitters? When I faced
similar issues, the answer was no.

So going with the lists:foldl/3 analogy, lists:foldl/3 is helpful because
there is a huge variety of cases of where it does work. I am not personally
convinced that's the case for delayed restarts. I am aware I am just one
datapoint though. :)

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

> Hi Jose :)
>
> > 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.
>
> Well, yes, in those cases you simply can't do it with delayed restarts and
> they are a poor fit for the case at hand ^^;
>
> I guess what I'm trying to say is... as an analogy off the top of my head,
> there are many list-related things you can do with lists:foldl and foldr,
> but you can't do _everything_ with them, and you shouldn't _try_ to do
> everything with them for the only reason that they exist. For some things
> it is simply better to use explicit recursion, some things can't be done
> any other way. But that is not an argument for not having foldl/foldr, is
> it?
>
> Kind regards,
> Maria
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20210617/748e9862/attachment.htm>


More information about the eeps mailing list