The idea is to start a new version of the service and do a quick hand-off of listening from old to new (possibly even switching back). This is particularly useful for code upgrades that aren't suitable for hot code loading. We're doing continuous integration this way, as hot code loading requires too much work and/or planning for us at this stage. It's currently an uncommon need but it would be a lot more common if it was well documented and easier to do.<div>
<br></div><div>As far as load balancers go, we're not using them. For our use case we don't need them, so why add the complexity and/or cost? There is port forwarding done by the OS kernel but I want to avoid requiring some setuid binary to do the privilege escalation that would be necessary to change ports on the fly. <span></span><br>
<br>Nginx does upgrades in a similar way. <a href="http://wiki.nginx.org/CommandLine#Upgrading_To_a_New_Binary_On_The_Fly">http://wiki.nginx.org/CommandLine#Upgrading_To_a_New_Binary_On_The_Fly</a><div><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">As with all proposed features I first need to understand what it's used for and why, and whether it'll be useful to other people. What you are doing just sounds very weird to me and it's the first time I hear of a need for something like this so at this point I'm neither trying to avoid anything nor considering it useful functionality, just wanting to understand why.<br>
<br>
On 05/15/2012 06:42 AM, Bob Ippolito wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, I want the other process to immediately take over. Requiring a load<br>
balancer change isn't an elegant solution, I don't understand why you're<br>
trying to avoid adding this useful functionality.<br>
<br>
On Monday, May 14, 2012, Loïc Hoguin wrote:<br>
<br>
You stop listening after you're done gracefully stopping your<br>
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<br>
that case you usually don't need to use the same listening port, you<br>
can just change your firewall/lb rules for the port redirection from<br>
80->P1 to 80->P2.<br>
<br>
On 05/15/2012 03:34 AM, Bob Ippolito wrote:<br>
<br>
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<br>
acceptors<br>
to 0. This should be added sometimes this summer after the<br>
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<br>
appropriate<br>
supervisors like I did. The application specific stuff<br>
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<br>
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<br>
<<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<br>
PM. It was in<br>
R14B03 that the behavior changed. I apparently have<br>
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<br>
to stop<br>
everything.<br>
<br>
For "server is overloaded" situations, you can very<br>
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<br>
a Req,<br>
returns<br>
a Req, and if you replied from within it it doesn't<br>
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<br>
accepting requests<br>
plus a short delay ought to do it. Some are long<br>
lived, which<br>
probably requires to send a shutdown message. Some<br>
apps may have<br>
connections critical enough that you don't want to<br>
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<br>
this is<br>
due to the<br>
fact<br>
Cowboy is using simple_one_for_one supervision?<br>
In Pre<br>
R15, if I<br>
recall<br>
correctly, the shutdown of sofo supervisors was<br>
asynchronous. The<br>
supervisor would just di
<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>
<<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ł<br>
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<br>
example.<br>
I've only<br>
investigated the case when supervisor is<br>
killed,<br>
so YMMV.<br>
Example code is attached. You may modify<br>
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<br>
is "no,<br>
it does not".<br>
<br>
When supervisor dies, your process is<br>
killed as<br>
via link<br>
mechanism, so it may leave some unprocessed<br>
messages in<br>
inbox. To make sure that every delivered<br>
message<br>
is served,<br>
you need to add process_flag(trap_exit,<br>
true).<br>
Messages that<br>
are sent after the moment when<br>
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<br>
following a<br>
shutdown<br>
message?<br>
<br>
If so how do I cleanly shutdown my<br>
gen_svr without<br>
loosing messages? I read in the<br>
supervisor child<br>
spec<br>
that a shutdown can be set to infinity<br>
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<br>
flawed and<br>
if so<br>
what other ways are there to cleanly<br>
shutting<br>
down my<br>
gen_svr without loosing messages?<br>
<br>
Many thanks,<br>
<br>
Andy.<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>
<<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>
______________________________<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>
<<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>
______________________________<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>
<<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>
<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>
<<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> <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>
<<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>
<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></div></div>