feedly team wrote:
[...]
using netstat, i see a moderate number (~80) of tomcat's sockets in
the CLOSE_WAIT state, not sure if this is relevant.
Approximately, because I am not sure I have this really understood yet :
a TCP CLOSE_WAIT state happens when the writing side of a TCP connection
has finished writing and (nicely) closes its side of the socket to
indicate the fact, but the reading side of the connection does not read
what is left in the buffers, so there is still some data unread in the
pipeline, and the reading side never closes the socket.
And now I'm stuck in my explanation, because I am not sure which side is
seeing the CLOSE_WAIT... ;-)
But anyway, it indicates a problem somewhere in one of the two
applications, my guess being the reading one.
It should do more reads to exhaust the remaining data, get an
end-of-stream, then close its side of the connection, but it never does.
There is apparently no timeout for that, so the OS can never get rid of
that socket, which probably leaves a bunch of things hanging around and
consuming resources that they shouldn't.
On one of our systems, I have occasionally seen this issue grow until
the point where the system seemed unable to accept new connections.
Now whether that has any bearing on your particular issue, I don't know.
But it sure indicates a logical problem somewhere.
There is quite a bit on the subject on Google, of unequal quality.
If someone knows a more rigorous explanation, please go ahead.
I will still add a purely sibjective and personal note : from personal
experience, this phenomenon seems to happens more frequently whith Java
applications than with others, so I would guess that there might be
something in the Java handling of sockets that makes it a bit harder to
write correct socket-handling code.
A Java expert may want to comment on that too.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
