Mark Thomas wrote:
...
For 1, it is not necessary. Stopping the app makes it eligible for GC.
However, Tomcat 7.0.11 onwards does stop it (see [1]) since this forces
the database connections to be closed immediately rather than waiting
for GC. Since this is viewed as a 'nice to have' rather than a bug (it
is not a memory leak) then it won't be back-ported to earlier versions.
I am wondering if this could not create the same phenomenon which I have seen with another
app a while ago : a number of connections, at the OS level, left in the CLOSE_WAIT state
until the next GC.
Scenario :
- a Java "connection object" is created, which contains a socket (OS-level
structure)
- the object is used, and then discarded, but without explicitly closing the
embedded socket
- the object, now without reference to it within Java, sits on the Heap,
waiting to be GC-ed
- but because it still has this unclosed socket in it, that socket still exists at the OS
level, and cannot be reclaimed by the OS
Slowly, such CLOSE_WAIT sockets accumulate, and in Linux at least, when there are a few
hundreds of them, the system suddenly becomes irresponsive to TCP/IP in general (no new
connections can be created for example).
Easy to diagnose : do this a few times and watch the output of
"netstat -pan | grep CLOSE_WAIT"
Then force a GC, and look again.
(Of course then, with a Tomcat version < 7.0.11)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
