[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133039#comment-14133039
]
Remko Popma commented on LOG4J2-819:
------------------------------------
Ralph, since LOG4J2-628 the Log4JLogEvent Clock is actually used for all
(non-async logger) event timestamps. Please see the
[constructor|http://logging.apache.org/log4j/2.x/log4j-core/xref/org/apache/logging/log4j/core/impl/Log4jLogEvent.html#145]
on line 145-155.
I don't oppose your solution, but there is something missing:
The Coarse/CachedClock classes are loaded because of the way ClockFactory is
coded. This has an undesired side effect that Tomcat ends up creating the
background threads for *both* CoarseCachedClock and CacheClock after the web
app is stopped. This happens *even* if Log4J uses SystemClock to create
timestamps.
So just managing a central Log4j clock instance in LoggerContext is not enough.
I propose we modify ClockFactory such that the class loader no longer loads
Coarse/CachedClock by accident. That would solve this Jira.
That leaves the possibility that the user _intentionally_ configures
CachedClock in a web application (which would also cause a memory leak).
Ralph's proposal to make Clock part of the LoggerContext life cycle would
address that concern.
I don't oppose that, but that will be significant work. We don't have a user
requesting this feature, so before we spend a lot of time on it I just want to
point out an alternative:
What about simply documenting on the site that CachedClock should not be used
by web applications? There is only one brief [mention
here|http://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync]
that CachedClock exists. CoarseCachedClock is never mentioned on the site. So I
doubt that this would inconvenience any users.
> 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]
