You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2014/09/11 01:55:34 UTC
[jira] [Commented] (LOG4J2-819) PermGen OutOfMemoryError when
reloading webapp on Tomcat 6
[ https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129390#comment-14129390 ]
Remko Popma commented on LOG4J2-819:
------------------------------------
I'm leaning towards not fixing this. Stopping (and re-starting!) clock threads brings too much complexity.
These clocks were designed to be used in ultralow (sub-microsecond) latency applications.
Web apps don't fall into that category.
Web apps should just use the default system clock. Using any other class gives them no benefits and only trouble.
I will update the site docs to that effect.
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org