[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131517#comment-14131517
]
Remko Popma edited comment on LOG4J2-819 at 9/12/14 1:42 PM:
-------------------------------------------------------------
[~costat] I'm having trouble reproducing the issue. You mentioned that you did
not configure any clock and that the CoarseCachedClock singleton is created
automatically by the classloader. That does not match what I am seeing. If I
call {{ClockFactory.getClock().currentTimeMillis()}} without any system
properties, no CachedClock or CoarseCachedClock singleton is created (and
neither are their associated updater threads).
I can even do {{CoarseCachedClock.class.getName()}} and I get the same result:
no CoarseCachedClock singleton and also no associated thread. I only see the
clock updater thread being started after explicitly calling
{{CoarseCachedClock.instance()}} or {{CachedClock.instance()}}.
So I wonder how the thread was created...
As far as I can see, the clock updater thread can only be started if:
# the application explicitly calls {{CoarseCachedClock.instance()}} or
{{CachedClock.instance()}}.
# system property {{log4j.Clock}} has one of these four values:
#* "CachedClock"
#* "CoarseCachedClock"
#* "org.apache.logging.log4j.core.util.CachedClock"
#* "org.apache.logging.log4j.core.util.CoarseCachedClock"
Can you double check that neither of the above is happening in your application?
was (Author: [email protected]):
[~costat] I'm having trouble reproducing the issue. You mentioned that you did
not configure any clock and that the CoarseCachedClock singleton is created
automatically by the classloader. That does not match what I am seeing. If I
call {{ClockFactory.getClock().currentTimeMillis()}} without any system
properties, no CachedClock or CoarseCachedClock singleton is created (and
neither are their associated updater threads).
I can even do {{CoarseCachedClock.class.getName()}} and I get the same result:
no CoarseCachedClock singleton and also no associated thread. I only see the
clock updater thread being started after explicitly calling
{{CoarseCachedClock.instance()}} or {{CachedClock.instance()}}.
So I wonder how the thread was created...
As far as I can see, the clock updater thread can only be started if:
# the application explicitly calls {{CoarseCachedClock.instance()}} or
{{CachedClock.instance()}}.
# system property {{log4j.Clock}} has one of these four values:
#* "CachedClock"
#* "CoarseCachedClock"
#* "org.apache.logging.log4j.core.util.CachedClock"
#* "org.apache.logging.log4j.core.util.CoarseCachedClock"
> 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: gg-log4j2-clocks.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]
