and for your points :) http://stackoverflow.com/questions/27603430/properly-close-tcp-server-when-using-cluster
On Thu, Dec 25, 2014 at 1:04 PM, Phani Kumar <[email protected]> wrote: > Yes, it is causing the problem. The application is not just a server to > exit the cluster. Based on some criteria we wanted to start server (accept > connections) or close server so that no worker should accept connections. > We need more control over here. > > Yes, as you said it looks it is the master which is not getting killed and > still accepting connections. > > Doesn't it inconsistent/ a bug or a gap? If we are using cluster no way we > an close server gracefully without killing node application. > > Should we file a jira? > > -Phani > > > > On Thu, Dec 25, 2014 at 1:48 AM, Sam Roberts <[email protected]> wrote: > >> On Tue, Dec 23, 2014 at 10:26 PM, Phani Kumar <[email protected]> wrote: >> > (same I posted in SO also couple of days back) >> >> Post the link so I can get SO points! :-) >> >> > I have below sample code where I am forking child processes, starting a >> TCP >> > server and closing the server after certain timeout. When I looked at >> TCP >> > connections after timeout, I still see that one connection is in >> listening >> > state. >> >> That would be the master. What happens in cluster is the master opens >> (once) a listening socket, and every worker who "listens" on that same >> port ever after just gets a duplicate descriptor for that single >> socket in the master, which is always in "listening" state, but that >> does not, in fact, accept any connections. The close event just means >> the socket in the worker is closed, the underlying "listening" socket >> may (and in this case, does) have other socket descriptors referencing >> it in other node processes. >> >> Its possible, in theory, for the master to notice that no worker is >> using the socket anymore, and close it. I'm not sure if that would be >> a feature, though. As-is, your connections are handshaked by the TCP >> stack, and available on the socket, and wait, so that a new worker >> that is forked AFTER the TCP connection has handshaked should start >> getting those connections. >> >> cluster is very, very biased in its activity. Its for persistently up >> symetrical TCP servers (workers may come and go, but the assumption is >> they keep coming back), and has giant caveats when used in other ways. >> Such as opening a TCP server, and closing it, but not exiting the >> cluster... which is what you are doing, is an edge case. >> >> Is this actually causing you problems, or did it just surprise you >> when poking around? Why are trying to close a TCP server, but not exit >> the cluster? >> >> Cheers, >> Sam >> >> -- >> Job board: http://jobs.nodejs.org/ >> New group rules: >> https://gist.github.com/othiym23/9886289#file-moderation-policy-md >> Old group rules: >> 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 unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/nodejs/CACmrRmSG%3DYH3MAK04PLNsSHbgAD%3D1eLC0iFkCQd56Ko46KC5MA%40mail.gmail.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > -Phani > -- -Phani -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAP1dm3kiuexeVORqw3ht1qfGFjaEqVc1oB6S84eu2jRYOQvdmw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
