<div dir="ltr"><div>Thanks Maria and Jan for another EEP!</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 17, 2021 at 3:01 PM Maria Scott <<a href="mailto:maria-12648430@hnc-agency.org">maria-12648430@hnc-agency.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Viktor :)<br>
<br>
> I support this EEP. :-)<br>
<br>
Glad to hear :)<br>
<br>
> It has been argued before that supervision trees are for fault-tolerance <br>
> of bugs, not network/external errors. But why not enable the use of <br>
> supervision subtrees for external faults too?<br>
<br>
Yes, I understand both sides of the argument, but yeah, why not? :)<br>
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.<br>
<br>
> If we add delays, then how about exponential backoff? e.g. doubling the <br>
> delay for each failed restart attempt. Is it worth considering too? It <br>
> has been suggested before and it's common for network re-attempts.<br>
<br>
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.<br>
<br>
> Just forbid the existence of the key restart_delay when restart type is <br>
> temporary.<br>
<br>
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.<br>
<br>
Regards,<br>
Maria<br>
_______________________________________________<br>
eeps mailing list<br>
<a href="mailto:eeps@erlang.org" target="_blank">eeps@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/eeps" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
</blockquote></div>