Hi Charles,
Thanks for the info. I recall a post of yours I read on the Nabble list related
to this stuff so I appreciate and value your feedback.
I think I misspoke earlier. When I said the memory is still littered with the
application classes, I mean virtually everything, thousands of dynamic Proxy
classes that seemed to be generated by Hibernate, all the Hibernate classes,
the Spring classes, it was virtually the entire application. What I suspect I
saw was the memory prior to GC. I had used the TC manager app to both stop the
app and to undeploy. How do I force a GC though? I tried using JConsole's GC
button, but clearly this didn't do the trick. Do I just leave Tomcat running
for some period of time?
As to the other info:
Other information you need to supply on your next posting:
1) Tomcat version
Tomcat 6.0.18
2) JRE/JDK version (including 32- or 64-bit)
JRE 1.6.0 Update 12 32 bit
3) platform you're running on
Windows 2003 R2
4) JVM command-line options used when starting Tomcat
-Xms512
-Xmx1024
-XX:MaxPermSize=128m
The permsize was bumped up a long time ago because Tomcat runs both a pure Java
app and a Grails application which generates a lot of dynamic classes, and
Hibernate and Spring are used in both. Some other info on the application
itself is that the customer instances where we're experiencing problems also
have a high client load (we have client apps that connect to our pure Java
server app) and they maintain long-lived socket connections to the server that
ping every 30s on the socket as a heartbeat. I don't think the Grails
application is causing a problem as the issue occurs even when the Grails app
is not (or is hardly) used. So the main activity would be the N clients pinging
away with each ping causing a DB roundtrip. At the moment the problem instances
have 1800 and 2700 concurrent client connections to the server. So the leak is
a LOT more noticeable than some of our customer instances where the client
count is much lower.
So the issue right now is a plan of attack to properly unload classes in order
to expose the likely culprit.
Many thanks,
Darryl Pentz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
