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
performance.)
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
