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 <evantah...@gmail.com> 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 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. > > -- -- 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.
