tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: CLOSE_WAIT and what to do about it
Date Wed, 08 Apr 2009 12:47:47 GMT
Peter Crowther wrote:
> If you have some way of forcing that Java process to collect garbage, you should do so.
 It's possible for sockets that haven't been close()d to hang around, unreferenced but not
yet garbage collected.  A full GC would collect any of these, finalizing them as it does and
hence closing the socket.  If a full GC doesn't close the socket, some other object is still
referencing it.
Hopping on that idea, and still considering the "try something from the 
outside, without modifying the code" kind of view :

This process is started as a daemon, with a "java" command-line.
Is it possible to add some arguments to that command-line to "induce" 
the JVM to do a GC more often ?
(I don't think that in this case it would have a very negative impact on 
It currently starts without any -D switches at all to the command-line, 
basically :
path/to/java/java -jar theapp.jar

The same question for the related Tomcat webapp (which I suspect of 
having the same issue).  But in that case I do have to be a bit more 
careful regarding the performance impact, although this webapp is pretty 
much all that is running in this Tomcat.
And that Tomcat (on some of our systems) starts under jsvc, and I don't 
really know where to set the parameters for that one under Linux.

Relatedly, does there exist any way to force a given JVM process to do a 
full GC interactively, but from a Linux command-line ?
I have full access to these systems, but usually only in SSH console 
mode, and I don't know if there is any kind of graphical GUI installed 
or accessible on them.
Basically, I'd like to see if triggering a GC reduces this number of 
lingering sockets.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message