Yes, I want the other process to immediately take over. Requiring a load balancer change isn't an elegant solution, I don't understand why you're trying to avoid adding this useful functionality.<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">You stop listening after you're done gracefully stopping your currently running processes.<br>

<br>
For HTTP that could be something like:<br>
<br>
Set acceptors to 0.<br>
Optionally set 'onrequest' hook to reply with a 503 (for keepalives).<br>
Gracefully stop your processes.<br>
Stop the listener.<br>
<br>
Or do you need another process to take over immediately? Because in that case you usually don't need to use the same listening port, you can just change your firewall/lb rules for the port redirection from 80->P1 to 80->P2.<br>

<br>
On 05/15/2012 03:34 AM, Bob Ippolito wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think that is sufficient, you will need to stop listening as<br>
well so the next OS process can take over.<br>
<br>
On Monday, May 14, 2012, Loïc Hoguin wrote:<br>
<br>
    This will be possible later on by reducing the number of acceptors<br>
    to 0. This should be added sometimes this summer after the acceptor<br>
    split happens in Cowboy.<br>
<br>
    On 05/14/2012 07:26 PM, Bob Ippolito wrote:<br>
<br>
        I agree that graceful shutdown is very application-specific.<br>
        However,<br>
        cowboy doesn't currently facilitate any sort of graceful<br>
        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<br>
        done on<br>
        your own with a process registry or a timeout, we used a<br>
        combination of<br>
        gproc and a timeout if things didn't shut down in an acceptable<br>
        time frame.<br>
<br>
        I would suggest something like cowboy:stop_listener/1, maybe<br>
        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<br>
        wrong<br>
            past that release, and will take a look if I find other<br>
        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<br>
        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,<br>
        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<br>
        connection by<br>
            setting the Connection header to "close").<br>
<br>
            And adding this:<br>
<br>
            For graceful shutdowns, well it's highly application<br>
        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<br>
        them.<br>
            It's up to the application implementor to devise the<br>
        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<br>
        due to the<br>
                fact<br>
                Cowboy is using simple_one_for_one supervision? In Pre<br>
        R15, if I<br>
                recall<br>
                correctly, the shutdown of sofo supervisors was<br>
        asynchronous. The<br>
                supervisor would just die and let its children figure<br>
        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<br>
        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<br>
        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<br>
        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<br>
        before<br>
                    killing its children; I think it's pretty normal<br>
        that some<br>
                    messages are left unprocessed.<br>
                    Bob, cowboy_requests_sup' shutdown strategy is<br>
        brutal_kill,<br>
                    is it<br>
                    documented somewhere that Cowboy waits before<br>
        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>

        <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>
        <<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<br>
        (Cowboy seems to<br>
                        fail to fulfill the promise of not killing<br>
        request processes<br>
                        after listener removal) and I have an example.<br>
        I've only<br>
                        investigated the case when supervisor is killed,<br>
        so YMMV.<br>
                        Example code is attached. You may modify it to<br>
        check the<br>
                        behavior in your case.<br>
<br>
                        Start supervisor tree with<br>
        exp_sup_sup:start_link(). Execute<br>
                        test with exp_sup_sup:test() and<br>
        exp_sup_sup:test_simple().<br>
<br>
                        In case of dying supervisor the answer is "no,<br>
        it does not".<br>
<br>
                        When supervisor dies, your process is killed as<br>
        via link<br>
                        mechanism, so it may leave some unprocessed<br>
        messages in<br>
                        inbox. To make sure that every delivered message<br>
        is served,<br>
                        you need to add process_flag(trap_exit, true).<br>
        Messages that<br>
                        are sent after the moment when supervisor dies<br>
        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<br>
        documentation<br>
                        so was wondering if anyone could confirm if<br>
        messages are<br>
                        still sent to a supervised gen_svr following a<br>
        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<br>
        spec<br>
                        that a shutdown can be set to infinity which i hoped<br>
                        would allow me to process the msg's in my<br>
        mailbox but if<br>
                        I do this will my module continue to receive<br>
        messages<br>
                        from other processes? Is my approach flawed and<br>
        if so<br>
                        what other ways are there to cleanly shutting<br>
        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>
        <<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>
        <<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>
        <<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>
        <<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>
        <<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>
<br>
<br>
    --<br>
    Loïc Hoguin<br>
    Erlang Cowboy<br>
    Nine Nines<br>
<br>
</blockquote>
<br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
</blockquote>