<div dir="ltr">Specifically for web applications, and more specifically for a webapp that can have long-running requests (measured in minutes), I've found it extremely convenient to have a supervised gen_server that simply tracks the start and end of each http request. It traps exits so that when it's told to shut down, it can enter a "terminate loop", and it doesn't terminate until all requests have completed or a timeout elapses. This is complemented by a shutdown timeout in its supervisor, which will hard kill it eventually, in the case that something goes terribly wrong. After that, it's just a matter of getting your supervisor/process start/stop in the correct order.</div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 23, 2017 at 9:07 AM PAILLEAU Eric <<a href="mailto:eric.pailleau@wanadoo.fr">eric.pailleau@wanadoo.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
in addition to other answers, it is worth noting that you can set<br>
a maximum time to VM to stop.<br>
<br>
<a href="http://erlang.org/doc/man/init.html" rel="noreferrer" target="_blank">http://erlang.org/doc/man/init.html</a><br>
<br>
"To limit the shutdown time, the time init is allowed to spend taking<br>
down applications, command-line flag -shutdown_time is to be used."<br>
<br>
this can be very useful when some processes are stuck in abnormal<br>
terminate work. But using this you can loose data obviously.<br>
Restart time is sometime more important than loosing some cleanup.<br>
<br>
Regards<br>
<br>
<br>
<br>
<br>
Le 23/12/2017 à 15:41, Fred Hebert a écrit :<br>
> On 12/23, Xavier Noria wrote:<br>
>><br>
>> But there's something that bugs me and prevents me from imagining<br>
>> complete<br>
>> and round solutions, which is shutting down. When shutting down (think<br>
>> autoescaling, deploys, etc.). I have a live system that needs to stop<br>
>> orderly.<br>
>><br>
>> Are there patterns or best practises about how to design this aspect<br>
>> of the<br>
>> system?<br>
><br>
> Good news! You already have this covered with OTP.<br>
><br>
> When shutting down a supervision tree, the supervisor will send down a<br>
> `shutdown` exit signal to each of its children in order. A child<br>
> supervisor will trap exit on this, and forward it to its own children<br>
> first.<br>
><br>
> If your worker has nothing special to do, just let it die. If it needs<br>
> some special cleanup, trap exit in the worker and `terminate` will be<br>
> called.<br>
><br>
> So the supervision structure you have that tells how the program boots<br>
> also tells how it shuts down. You do have to be careful about the<br>
> handling of timeouts though (or brutal_kill will catch you up).<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>