[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133068#comment-14133068
]
Remko Popma edited comment on LOG4J2-819 at 9/14/14 3:49 AM:
-------------------------------------------------------------
Yes, you are both correct.
Gary's suggestion to lazily initialize the static variables is also sufficient
to resolve this Jira (unintentionally started threads causing mem leaks).
Removing the static variables and managing a single Clock instance centrally in
LoggerContext may be the right thing to do because (in addition to fixing this
Jira) it would make it possible for web apps to use CachedClock. The trade-off
is that it would be significantly more work. So is that worth it?
was (Author: [email protected]):
Yes, you are both correct.
Gary's suggestion to lazily initialize the static variables is also sufficient
to resolve this Jira (unintentionally started threads causing mem leaks).
Removing the static variables and managing a single Clock instance centrally in
LoggerContext may be the right thing to do because it would make it possible
for web apps to use CachedClock. The trade-off is that it would be
significantly more work. So is that worth it?
> PermGen OutOfMemoryError when reloading webapp on Tomcat 6
> ----------------------------------------------------------
>
> Key: LOG4J2-819
> URL: https://issues.apache.org/jira/browse/LOG4J2-819
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.2
> Environment: Tomcat 6
> Reporter: Costa Theodosiou
> Priority: Critical
> Attachments: demo.zip, demorun-tomcat6-with-reload.zip, demorun.zip,
> gg-log4j2-clocks-interrupts.patch, gg-log4j2-clocks-v2.patch
>
>
> When reloading an application 3 or 4 times in Tomcat 6, the application
> crashes with a "java.lang.OutOfMemoryError: PermGen space" exception.
> After some investigation using the "When all else fails" section of
> https://wiki.apache.org/tomcat/OutOfMemory in conjunction with Java VisualVM,
> I have narrowed down the problem to the Thread created within
> org.apache.logging.log4j.core.util.CoarseCachedClock.
> When a Thread is created, it contains a reference to the classloader that it
> was created with. In this case, the Thread's contextClassLoader field
> contains a reference to the WebappClassLoader. When Tomcat attempts to unload
> the webapp, the Thread still holds onto this reference which prevents
> WebappClassLoader from being freed.
> Perhaps the Log4jServletContextListener (Log4jWebInitializerImpl) can be made
> to stop the CoarseCachedClock thread.
> I believe this is not an obvious issue on Tomcat 7 due to
> https://wiki.apache.org/tomcat/MemoryLeakProtection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
