I don't think that is sufficient, you will need to stop listening as well so the next OS process can take over. <span></span><br><br>On Monday, May 14, 2012, Loïc Hoguin  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This will be possible later on by reducing the number of acceptors to 0. This should be added sometimes this summer after the acceptor split happens in Cowboy.<br>
<br>
On 05/14/2012 07:26 PM, Bob Ippolito wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree that graceful shutdown is very application-specific. However,<br>
cowboy doesn't currently facilitate any sort of graceful shutdown unless<br>
you read the source code and poke directly at the appropriate<br>
supervisors like I did. The application specific stuff is easily done on<br>
your own with a process registry or a timeout, we used a combination of<br>
gproc and a timeout if things didn't shut down in an acceptable time frame.<br>
<br>
I would suggest something like cowboy:stop_listener/1, maybe something<br>
like cowboy:stop_listening/1 or cowboy:stop_accepting/1.<br>
<br>
On Sun, May 13, 2012 at 11:02 PM, Loïc Hoguin <<a>essen@ninenines.eu</a><br>
<mailto:<a>essen@ninenines.eu</a>>> wrote:<br>
<br>
    Right, this is pretty much what I said to Paul in PM. It was in<br>
    R14B03 that the behavior changed. I apparently have a @todo wrong<br>
    past that release, and will take a look if I find other things to<br>
    fix in the docs.<br>
<br>
    Copy pasting my private reply on this:<br>
<br>
    Ultimately if we remove the listener I think we want to stop everything.<br>
<br>
    For "server is overloaded" situations, you can very well use the<br>
    'onrequest' hook which can be set or changed dynamically through<br>
    cowboy:set_protocol_options, in addition to giving it in<br>
    start_listener. Takes a fun that has a single arg as a Req, returns<br>
    a Req, and if you replied from within it it doesn't dispatch the<br>
    request and stops there (you can also force close the connection by<br>
    setting the Connection header to "close").<br>
<br>
    And adding this:<br>
<br>
    For graceful shutdowns, well it's highly application dependent. Some<br>
    apps are just short lived connections, so not accepting requests<br>
    plus a short delay ought to do it. Some are long lived, which<br>
    probably requires to send a shutdown message. Some apps may have<br>
    connections critical enough that you don't want to shutdown them.<br>
    It's up to the application implementor to devise the strategy to use<br>
    for stopping.<br>
<br>
<br>
    On 05/14/2012 02:34 AM, Fred Hebert wrote:<br>
<br>
        This is just a guess, but is it possible that this is due to the<br>
        fact<br>
        Cowboy is using simple_one_for_one supervision? In Pre R15, if I<br>
        recall<br>
        correctly, the shutdown of sofo supervisors was asynchronous. The<br>
        supervisor would just die and let its children figure out it was<br>
        gone.<br>
<br>
        Starting with R15, things started being synchronous and the<br>
        supervisor<br>
        would wait. A brutal kill that made things work fine before R15<br>
        (excluding the issue of the application master killing<br>
        everything) could<br>
        start breaking in later versions.<br>
<br>
        Again, this is just a guess, without looking at the source or<br>
        anything.<br>
<br>
        On Sun May 13 14:12:18 2012, Bob Ippolito wrote:<br>
<br>
            Yes, it is documented that request processes continue after<br>
            you stop<br>
            the listener. This is incorrect.<br>
<br>
            On Sunday, May 13, 2012, Anthony Ramine wrote:<br>
<br>
            Paweł, from what I gather your supervisor waits 1 ms before<br>
            killing its children; I think it's pretty normal that some<br>
            messages are left unprocessed.<br>
            Bob, cowboy_requests_sup' shutdown strategy is brutal_kill,<br>
            is it<br>
            documented somewhere that Cowboy waits before killing requests'<br>
            processes?<br>
<br>
            Regards,<br>
<br>
            --<br>
            Anthony Ramine<br>
<br>
<br>
<br>
<br>
            Le 10 mai 2012 à 22:37, Bob Ippolito a écrit :<br>
<br>
                I had the same problem with Cowboy recently, really<br>
                ought to file<br>
                an issue to at least fix the docs for that.<br>
<br>
                For my app I wanted to implement a graceful shutdown<br>
                that stopped<br>
                accepting new connections but allowed existing requests to<br>
                finish. The waiting part I implemented by adding a gproc<br>
                local<br>
                property to the workers that I wanted to wait for and then<br>
                monitoring them.<br>
<br>
                Looks like this:<br>
                <a href="https://gist.github.com/__2655724" target="_blank">https://gist.github.com/__<u></u>2655724</a><br>
                <<a href="https://gist.github.com/2655724" target="_blank">https://gist.github.com/<u></u>2655724</a>><br>
<br>
                On Thu, May 10, 2012 at 2:53 AM, Paweł Peregud<br>
                <<a>paulperegud@gmail.com</a> <mailto:<a>paulperegud@gmail.com</a>><br>
                <javascript:_e({}, 'cvml',<br>
                '<a>paulperegud@gmail.com</a><br>
                <mailto:<a>paulperegud@gmail.com</a>>');>> wrote:<br>
<br>
                I was having fun with supervisors yesterday (Cowboy seems to<br>
                fail to fulfill the promise of not killing request processes<br>
                after listener removal) and I have an example. I've only<br>
                investigated the case when supervisor is killed, so YMMV.<br>
                Example code is attached. You may modify it to check the<br>
                behavior in your case.<br>
<br>
                Start supervisor tree with exp_sup_sup:start_link(). Execute<br>
                test with exp_sup_sup:test() and exp_sup_sup:test_simple().<br>
<br>
                In case of dying supervisor the answer is "no, it does not".<br>
<br>
                When supervisor dies, your process is killed as via link<br>
                mechanism, so it may leave some unprocessed messages in<br>
                inbox. To make sure that every delivered message is served,<br>
                you need to add process_flag(trap_exit, true). Messages that<br>
                are sent after the moment when supervisor dies are not<br>
                processed.<br>
<br>
                Best regards,<br>
<br>
                Paul.<br>
<br>
<br>
                On May 9, 2012 11:06 AM, "Andy Richards"<br>
                <andy.richards.iit@googlemail.<u></u>__com<br>
                <mailto:<a>andy.richards.iit@googlemail.com</a>><br>
                <javascript:_e({}, 'cvml',<br>
                'andy.richards.iit@googlemail.<u></u>__com<br>
                <mailto:<a>andy.richards.iit@googlemail.com</a>>');>> wrote:<br>
<br>
                Hi,<br>
<br>
                I can't seem to see any confirmation in the documentation<br>
                so was wondering if anyone could confirm if messages are<br>
                still sent to a supervised gen_svr following a shutdown<br>
                message?<br>
<br>
                If so how do I cleanly shutdown my gen_svr without<br>
                loosing messages? I read in the supervisor child spec<br>
                that a shutdown can be set to infinity which i hoped<br>
                would allow me to process the msg's in my mailbox but if<br>
                I do this will my module continue to receive messages<br>
                from other processes? Is my approach flawed and if so<br>
                what other ways are there to cleanly shutting down my<br>
                gen_svr without loosing messages?<br>
<br>
                Many thanks,<br>
<br>
                Andy.<br>
                ______________________________<u></u>___________________<br>
                erlang-questions mailing list<br>
                <a>erlang-questions@erlang.org</a><br>
                <mailto:<a>erlang-questions@erlang.org</a>> <javascript:_e({},<br>
                'cvml',<br>
                '<a>erlang-questions@erlang.org</a><br>
                <mailto:<a>erlang-questions@erlang.org</a>>')__;><br>
                <a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
                <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
<br>
                ______________________________<u></u>___________________<br>
                erlang-questions mailing list<br>
                <a>erlang-questions@erlang.org</a><br>
                <mailto:<a>erlang-questions@erlang.org</a>> <javascript:_e({},<br>
                'cvml',<br>
                '<a>erlang-questions@erlang.org</a><br>
                <mailto:<a>erlang-questions@erlang.org</a>>')__;><br>
                <a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
                <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
<br>
                ______________________________<u></u>___________________<br>
                erlang-questions mailing list<br>
                <a>erlang-questions@erlang.org</a><br>
                <mailto:<a>erlang-questions@erlang.org</a>> <javascript:_e({},<br>
                'cvml',<br>
                '<a>erlang-questions@erlang.org</a><br>
                <mailto:<a>erlang-questions@erlang.org</a>>')__;><br>
                <a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
                <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
<br>
<br>
<br>
            ______________________________<u></u>___________________<br>
            erlang-questions mailing list<br>
            <a>erlang-questions@erlang.org</a> <mailto:<a>erlang-questions@erlang.org</a>><br>
            <a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
            <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
        ______________________________<u></u>___________________<br>
        erlang-questions mailing list<br>
        <a>erlang-questions@erlang.org</a> <mailto:<a>erlang-questions@erlang.org</a>><br>
        <a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
        <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
<br>
<br>
    --<br>
    Loïc Hoguin<br>
    Erlang Cowboy<br>
    Nine Nines<br>
<br>
<br>
</blockquote>
<br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
</blockquote>