commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31286] New: - Memory leaks in JBoss due to LogFactory cache
Date Sat, 18 Sep 2004 11:51:03 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31286>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31286

Memory leaks in JBoss due to LogFactory cache

           Summary: Memory leaks in JBoss due to LogFactory cache
           Product: Commons
           Version: 1.0.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Logging
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: ayud@mail.ru


LogFactory.java maintains a static cache (Hashtable) of LogFactories, keyed by 
context ClassLoader. In JBoss, and may be in many other J2EE containers, each 
hot-redeployment of a J2EE application makes a new class loader for the 
application, destroying all references to the old one. However, commons-logging.
jar is loaded by a parent classloader which is common for all applications, and 
still maintains hard references to would-be-dead ClassLoaders of undeployed 
applications. This leads to significant memory leaks, because all static members 
of all classes of the undeployed applications do not become a subject for GC. It 
would be excellent if this LogFactory caching could be disabled through a config 
or a WeakHashMap is used instead of Hashtable.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message