[
https://issues.apache.org/jira/browse/LOGGING-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated LOGGING-51:
-----------------------------------
Fix Version/s: 1.1.0
> [logging] Memory leaks in JBoss due to LogFactory cache
> -------------------------------------------------------
>
> Key: LOGGING-51
> URL: https://issues.apache.org/jira/browse/LOGGING-51
> Project: Commons Logging
> Issue Type: Bug
> Affects Versions: 1.0.4
> Environment: Operating System: All
> Platform: All
> Reporter: Alexei Yudichev
> Fix For: 1.1.0
>
> Attachments: JCL-guide.diff, LogFactory.diff, LogFactoryTest.diff,
> memoryleaktest.zip, patch.txt, WeakHashtable.java, WeakHashtable_javadoc.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
