Re: web app using log4j not garbage collected when shutdown with tomcat manager app

[Ceki Gülcü <ce...@qos.ch>]

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