<div dir="ltr"><div>Hi!</div><div><br></div><div>See answer below,</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den sön 2 maj 2021 kl 21:01 skrev Nicolas Martyanoff <<a href="mailto:khaelin@gmail.com">khaelin@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi,<br>
<br>
I originally posted this email on erlang-patches, but I just realized<br>
most developers are on erlang-questions instead. I believe this could be<br>
of interest.<br>
<br>
<br></blockquote><div><br></div><div>Erlang-patches is legacy, we use GitHub instead, and yes erlang-questions is still a place for discussions.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nine years ago, an interesting patch [1] was submitted by Richard Carlsson<br>
allowing to delay the re-creation of failed children in supervisors.<br>
<br>
After a quick discussions, the official answer was that the OTP team<br>
would discuss about it [2]. There is no further message on the mailing<br>
list.<br>
<br>
Was there an official response ?<br>
<br></blockquote><div><br></div><div>Well, this was some time ago so I am unsure of how it was communicated. But the conclusion was that we did see merit in the idea but that we were not able to include something that would be backwards incompatible by default. To be able to change defaults we need to have a phasing out mechanism and period of testing what<br>problems it might cause legacy code. We also did not have an immediate own use case for this that could motivate it to be prioritized for us to put much of our own time into it, and hence it requires a bigger effort from the contributor to motivate and test and think through all scenarios.  Alas, we do not have the luxury to persue all ideas that we think are good ones. One example of something that we had wanted to do for a long time, and actually finally got to do, is gen_statem.  The recent contribution to supervisors<br>of significant children is an example of a successful Open Source contribution where we also happened to have an immediate use case. <br> <br>Regards Ingela - Erlang OTP/Team - Ericsson AB<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have various supervisors whose children handle network connections.<br>
When something goes wrong with the connection, children die and are<br>
immediately restarted. Most of the times, errors are transient (remote<br>
server restarting, temporary network issue, etc.), but retrying without<br>
any delay is pretty much guaranteed to fail again. And of course after a<br>
few retries, the application dies which is unacceptable.<br>
<br>
This kind of behaviour is a huge problem: it fills logs with multiple<br>
copies of identical errors and causes a system failure.<br>
<br>
In general, if I could, I would use restart delays with exponential<br>
backoff everywhere because in practice, restarting immediately is almost<br>
never the right approach: code errors do not disappear when restarting<br>
so they are going to get triggered again immediately, and external errors<br>
are not magically fixed by retrying without any delay.<br>
<br>
Is there still interest for this patch ?<br>
<br>
[1] <a href="https://erlang.org/pipermail/erlang-patches/2012-January/002575.html" rel="noreferrer" target="_blank">https://erlang.org/pipermail/erlang-patches/2012-January/002575.html</a><br>
[2] <a href="https://erlang.org/pipermail/erlang-patches/2012-January/002597.html" rel="noreferrer" target="_blank">https://erlang.org/pipermail/erlang-patches/2012-January/002597.html</a><br>
<br>
-- <br>
Nicolas Martyanoff<br>
<a href="http://snowsyn.net" rel="noreferrer" target="_blank">http://snowsyn.net</a><br>
<a href="mailto:khaelin@gmail.com" target="_blank">khaelin@gmail.com</a><br>
</blockquote></div></div></div>