Ceki, I think I've found a workaround for this problem.
Debugging the log4j property configuration code when executing test case 3, I noticed it used the java.beans package in PropertySetter to set the ConversionPattern property of the appender layout object. This code doesn't get executed in the other testcases because no Layout parameters (including ConversionPattern) are specified (at least not specified via the configuration file). After googling a bit on "Inspector", "memory", "leak" I found a few clues that led to the inspection of the java.beans.Introspector class. This class includes the following comment in its javadoc: * Because the Introspector caches BeanInfo classes for better performance, * take care if you use it in an application that uses * multiple class loaders. * In general, when you destroy a <code>ClassLoader</code> * that has been used to introspect classes, * you should use the * [EMAIL PROTECTED] #flushCaches <code>Introspector.flushCaches</code>} * or * [EMAIL PROTECTED] #flushFromCaches <code>Introspector.flushFromCaches</code>} method * to flush all of the introspected classes out of the cache. I then added a call to Introspector.flushCaches() in SimpleServlet.destroy() after the call to LogManager.shutdown(). With this additional line of code, test case 3 is now successful - the web app classes and the tomcat web app class loader are now garbage collected. Does this seem like a reasonable explanation/solution? This doesn't appear to be a log4j issue (I hope I didn't cause anyone any extra work). I would guess that maybe Tomcat should call Introspector.flushCaches() when it shuts down a web app since it's throwing away the classloader for the web app. For now, I'll include this line of code during web app shutdown. Hope this helps, -Jay > -----Original Message----- > From: Ceki G�lc� [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 22, 2004 7:23 AM > To: Log4J Users List > Subject: Re: web app using log4j not garbage collected when > shutdown with tomcat manager app > > > Jay, > > First, thank you for providing such a detailed and precise report. > > Looking at the differences between different tests, I find cases 3 and > 4 most interesting to compare because they are nearly identical in > configuration but while the former test fails the latter > succeeds. Their only difference is that Test 3 uses > the a date conversion specifier (%d{DATE}) while Test 4 > only a relative time converter. In light of this > difference, it is impossible to explain why test 3 fails > while test 4 succeeds. > > Before spending more time about this problem, are you > sure that failure of test 3 and success of test 4 are reproducible? > > At 06:23 PM 9/21/2004, Paulsen, Jay wrote: > >Are there any known problems with using the Tomcat manager app to > >shutdown web apps that use log4j? I have a web app that > leaks memory > >everytime I use the manager app to shut it down. To help narrow the > >problem down, I set up a simple web app with one servlet and log4j > >1.2.8. Depending on what type of log4j configuration the > web app uses, > >the web app classloader does not get garbage collected which > means all > >of the classes it loaded and any static references that > these classes > >may have all stay in memory. When the manager app is used > to restart > >the app, a new webapp class loader is created and the > classes for the > >web are loaded again. The old class loader is pinned in > memory by some > >reference. > > > > > >All tests used this log4j configuration in log4j.properties: > >log4j.debug=true > >log4j.rootLogger=DEBUG, CONSOLE > >log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender > > > >Each test deployed log4j.jar in the web app context class > path. A URI > >of the web app was invoked to load the web app's servlet. > The app was > >then shutdown using the Tomcat manager app. A memory > snapshot was then > >taken with YourKit Java Profiler 2.5.1 to inspect the classes and > >instances still remaining in memory. > > > >Test 1: Simple layout: > >log4j.appender.CONSOLE.layout=org.apache.log4j.SimpleLayout > >Result: successful - web app garbage collected > > > >Test 2: Pattern layout with no conversion pattern specified: > >log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout > >Result: successful - web app garbage collected > > > >Test 3: Pattern layout with a conversion pattern specified: > >log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout > >log4j.appender.CONSOLE.layout.ConversionPattern=%d{DATE} %t > %-5p [%x] > >%c %m%n > >Result: unsuccessful - web app and tomcat webapp classloader > still in > >memory - not garbage collected > > > >Test 4: Log4J configured with call to BasicConfigurator.configure() > >instead of using log4j.properties file. > >Result: successful - web app garbage collected > > > >Test 5: Same as Test 3 except now log4j.jar deployed in > >tomcat/shared/lib classpath instead of web app context class path: > >Result: successful - web app garbage collected (log4j classes and > >instances still in memory since the shared class path classloader is > >not > >reloaded) > > > > > >Am I doing something wrong or out of the ordinary here or is > there some > >issue with the configuration of a ConversionPattern using the > >properties file? Is it possible that something in this code > is holding > >onto a reference to the web app class loader or some class > of the web app? > > > >Any feedback is appreciated. > >-Jay > > > > -- > Ceki G�lc� > > For log4j documentation consider "The complete log4j manual" > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
