I originally started down this path trying to find a memory leak (involving commons-logging etc). I now have a more general question:
I've created an almost empty context. It contains 1 servlet which contains an arraylist (just to create a large object that is easier to see in memory graphs) and a default jsp page (as created by the maven webapp archetype). I deploy this along with the tomcat manager into tomcat 5.5.28, which is the standard tar.gz download with all the extra webapps stripped out of server/webapps (except for manager) and webapps. This means that there are 2 WebappClassLoader instances in memory, one for each context. This seems correct. There are also 2 WebappLoader instances in memory, I assume one for each context which also seems correct. Now my understanding of the WebappClassLoader is that there is and instance for each context and eacg class loader is used to load classes for that context. This allows for dynamic class loading and some (?) isolation for each context. My assumption (partially from what I have read) is that when the context is undeployed tomcat severs its references to the class loader and thus the gc process can clean up all the leftovers... Is this incorrect? I've deployed the very minimal context into tomcat and then undeployed it via the manager. I used VisualVM to look and the heapdumps from before and after. >From the before heapdump I saw what I expected: 2 WebappClassLoaders and 2 >WebappLoaders. After I saw: 2 WebappClassLoaders and 1 WebappLoader, which is not what I expected. Tomact seems to have retained 1 on the WebappClassLoader instances. I have two questions at this point: 1. From the Javadocs both WebappClassLoader and WebappLoader are class loaders. What are the differences and why does Tomcat use both? 2. Why would Tomcat be cleaning up the WebappLoader instance everytime successfully but seems to 'hang-on' to the WebappClassLoader instance? Thanks Gerwood --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
