webapp references, classloaders and GC (oh my)

[Tim Lucia <ti...@yahoo.com>]

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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org