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 -- 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/CAP1dm3kQEBZDv3-iu4k_wn09h4q1Co_5sq0KUmJRYrurJG0s%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
