I have a question about references held to my webapp from Tomcat. I have observed the behavior below on both Red Had EL V.4, and on WinXP, using Tomcat 5.5, and JDK 1.5. I used JProfiler to trace the allocations.
Some background: The environment here is such that we have a shared sandbox for QA, so developers are deploying (by copying some changed resource files, which are processed by the servlets) directly into the WEB-INF/classes/... area of the webapp. This causes (intentionally) a reload of the context, either by (and I have tried both ways) auto reloading (reload="true"), or by manual reloading (/manager/html/reload?path=/). What the profiler shows me is that my ServletContextListener gets reloaded every time, and there is one per reload (each in its own classloader.) This is as expected. When "enough" of them are loaded, GC runs (or if I run it manually from the profiler), all but two or three are GC'd. The three that remain are allocated by: 1. org.apache.catalina.startup.Bootstrap -- On Tomcat startup 2. org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor -- on auto-reload 3. org.apache.tomcat.util.net.AprEndpoint$Worker - org.apache.catalina.manager.HTMLManagerServlet (/manager/html/reload) While this does not cause PermGen problems for any one developer, it does cause the shared database server to run out of connections, because each developer has up to 3 "pools" (after GC, might be 8 or 10 before GC) per Tomcat, and some have clusters which means 2 X n pools. It appears, from watching the connections at the server, that the connections remain as long as one of the three references above remain. I can see clearly from logging that the ServletContextListener.contextInitialized() and ServletContextListener.contextDestroyed() methods are called as expected, however, the webapp is still not GC'd. I have shown this to be the case with a simple, 2-class webapp - one class implements ServletContextListener (and does nothing whatsoever in its two methods), and the other extends HttpServlet, looks up a JNDI resource, gets the DataSource, connects, and reports the connection is good (or bad). I took out all logging in the process, as that has been known (in the past anyway) to cause PermGen "leaks". I can mitigate things for the time being by reducing the size of the developer pools and/or increasing the number of connections in the database, but I would still like to understand what is going on. Any ideas or insights would be appreciated. Thanks, Tim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]