In my server, I start new child processes first, and than do server.close() the old child processes, which can avoid refusing new connections between stop and start.
If all connections disconnected after server.close(), the child process will exit. But if your client connections are long connections, you may have to close them at appropriate time. On Sunday, June 9, 2013 1:18:48 AM UTC+8, Isaac Schlueter wrote: > > Oh, it looks like I didn't document the repl that ClusterMaster > creates! I'll get on that. There are some open issues about it, I > guess I thought about closing them, but didn't *actually* close them. > My bad. > > In the meantime, you can dig into the npm-www source code to see what it > does. > > @Evan: > Besides calling server.close(), it's also important to call > process.disconnect() in the worker, so that the master gets the > disconnect event, and knows to spin up a new worker. Kill any other > persistent connections/etc, and then just expect it to die naturally. > > From there, it's usually a good idea to give the process a maximum > amount of time before it gets killed, in case the graceful shutdown > doesn't complete. ClusterMaster defaults to 2 seconds, I think, which > is pretty fast. In some cases, you may want as much as 120s, so that > HTTP KeepAlive connections can still be handled properly. > > I'm a little annoyed that server.close() makes the server keep sending > Connection:Keep-Alive headers. It'd be nice if the response objects > could terminate the connection automatically (and send > Connection:Close) if the server is no longer listening. We've > discussed doing this in node core, but in the meantime, a module for > this would be nice. Substack's "destroyer" is a bit too agressive for > this use case. > > > On Fri, Jun 7, 2013 at 8:28 PM, Evan <evant...@gmail.com <javascript:>> > wrote: > > @Isaacs Thanks for the module! It has a nice clean syntax. I may replace > > actionHero's cluster server with it :D > > > > I too agree that having a 'graceful reload' feature in clustered > deployments > > is a great feature. This is especially useful when you host the app > > yourself and don't rely on providers like appfog and heroku where > > "deployments" are literally new "servers" switched at the load balancer. > > However, I am in agreement with Isaacs that building a "graceful reload" > > into node's core cluster module is a bad idea. I think that doing so > would > > create a very complex API which is also very likely not to cover > everyone's > > use cases. > > > > Some examples: > > > > If your app is just an http(s) server, all you need to do is call > > `server.close()`. Node is awesome and the server will stop handling new > > connections, and will still finish existing requests. However, how do > you > > know to wait until all requests are complete before terminating this > child? > > How long do you wait? What if there are websockets bound to this > server? > > Will your clients know how to reconnect? What if you have a socket/tls > > server? You probably need to signal each client with a 'goodbye' > message > > and be sure that whatever they are working on is complete. Perhaps most > > importantly, what if your server is processing some background tasks? > You > > need to be sure that they are allowed to finish, less you loose the job > they > > are working on. > > > > Here are links to my examples above. These are all "teardown" functions > > which every worker in the custer does when it is signaled to shut down > (and > > they are all from one application!). > > > > Web (http/https) server: > > > https://github.com/evantahler/actionHero/blob/master/servers/web.js#L66-L69 > > > > Telnet/TLS socket server: > > > https://github.com/evantahler/actionHero/blob/master/servers/socket.js#L214-L239 > > > > > Background Task Worker: > > > https://github.com/evantahler/actionHero/blob/master/initializers/taskProcessor.js#L27-L43 > > > > > > > > > On Friday, June 7, 2013 6:26:57 PM UTC-7, ryandesign wrote: > >> > >> > >> On Jun 7, 2013, at 19:10, Isaac Schlueter wrote: > >> > >> > I do this with the npmjs.org site using the cluster-master module. > >> > > >> > https://npmjs.org/package/cluster-master > >> > >> Thanks, I'm sure I've heard of that before, and will remember to look > into > >> it once I get to the point of deploying. > >> > >> > >> > I only have to restart the main process if there's a change to the > >> > main server.js file. Otherwise, I log into the repl, and I can > >> > restart workers one by one, resize the cluster, etc. > >> > >> I guess I don't understand how this is accomplished. What repl are you > >> talking about? Is this something custom you've written for the npmjs > web > >> site or is this easily available to anyone's nodejs site using the > standard > >> repl that appears when you run "node"? Could you point me to an > example? > >> > >> > >> > Getting all the edge cases handled properly is very app-specific, and > >> > in multi-machine setups, it will be completely extraneous. > >> > > >> > So, unlike Ben, I would reject a pull request flat-out for this > >> > feature, unless someone could present a *very* compelling case for > why > >> > everyone ought to have the same logic in all their apps. I don't > >> > believe that this belongs in core. > >> > >> Regardless of whether you run a single node process on a single server > or > >> several processes on several servers, most everyone will eventually > want to > >> deploy an updated version of the code and restart the server, and I > don't > >> think it's controversial to claim that doing so gracefully, without > losing > >> any connections, is best. Why, then, should each developer need to > figure > >> out anew how to do that, especially when as you say it's difficult to > get > >> right? > >> > >> > > -- > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to nod...@googlegroups.com<javascript:> > > To unsubscribe from this group, send email to > > nodejs+un...@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "nodejs" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to nodejs+un...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
