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
<[email protected] <mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
http://erlang.org/mailman/listinfo/eeps
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
