Yes, it is documented that request processes continue after you stop the listener. This is incorrect. <span></span><br><br>On Sunday, May 13, 2012, Anthony Ramine  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Paweł, from what I gather your supervisor waits 1 ms before killing its children; I think it's pretty normal that some messages are left unprocessed.</div><div>Bob, cowboy_requests_sup' shutdown strategy is brutal_kill, is it documented somewhere that Cowboy waits before killing requests' processes?</div>
<div><br></div><div>Regards,</div><div><br></div><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div>
--</div><div>Anthony Ramine</div><div><br></div><div><br></div></span><br>
</div>
<br><div><div>Le 10 mai 2012 à 22:37, Bob Ippolito a écrit :</div><br><blockquote type="cite">I had the same problem with Cowboy recently, really ought to file an issue to at least fix the docs for that.<div><br></div><div>
For my app I wanted to implement a graceful shutdown that stopped accepting new connections but allowed existing requests to finish. The waiting part I implemented by adding a gproc local property to the workers that I wanted to wait for and then monitoring them.</div>

<div><br></div><div>Looks like this:</div><div><a href="https://gist.github.com/2655724" target="_blank">https://gist.github.com/2655724</a><br><br><div class="gmail_quote">On Thu, May 10, 2012 at 2:53 AM, Paweł Peregud <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'paulperegud@gmail.com');" target="_blank">paulperegud@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>I was having fun with supervisors yesterday (Cowboy seems to fail to fulfill the promise of not killing request processes after listener removal) and I have an example. I've only investigated the case when supervisor is killed, so YMMV. Example code is attached. You may modify it to check the behavior in your case.</p>
<p>Start supervisor tree with exp_sup_sup:start_link(). Execute test with exp_sup_sup:test() and exp_sup_sup:test_simple().</p><p>In case of dying supervisor the answer is "no, it does not".</p><p>When supervisor dies, your process is killed as via link mechanism, so it may leave some unprocessed messages in inbox. To make sure that every delivered message is served, you need to add process_flag(trap_exit, true). Messages that are sent after the moment when supervisor dies are not processed.</p>
<p>Best regards, <br></p><p>Paul.<br></p><div><div><div><br></div><div class="gmail_quote">On May 9, 2012 11:06 AM, "Andy Richards" <<a href="javascript:_e({}, 'cvml', 'andy.richards.iit@googlemail.com');" target="_blank">andy.richards.iit@googlemail.com</a>> wrote:<br type="attribution">


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I can't seem to see any confirmation in the documentation so was wondering if anyone could confirm if messages are still sent to a supervised gen_svr following a shutdown message?<br>
<br>
If so how do I cleanly shutdown my gen_svr without loosing messages? I read in the supervisor child spec that a shutdown can be set to infinity which i hoped would allow me to process the msg's in my mailbox but if I do this will my module continue to receive messages from other processes? Is my approach flawed and if so what other ways are there to cleanly shutting down my gen_svr without loosing messages?<br>




<br>
Many thanks,<br>
<br>
Andy.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="javascript:_e({}, 'cvml', 'erlang-questions@erlang.org');" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="javascript:_e({}, 'cvml', 'erlang-questions@erlang.org');" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>erlang-questions mailing list<br><a href="javascript:_e({}, 'cvml', 'erlang-questions@erlang.org');" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></blockquote>