[
https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131924#comment-14131924
]
Ralph Goers commented on LOG4J2-819:
------------------------------------
I am having problems with all of this.
First, I would expect CoarseCachedClock to be an instance of CachedClock. It
isn't. I would expect a CachedClock to have extra methods like stop() that
SystemClock doesn't need.
If log4j-core is in the Tomcat lib directory then Log4jLogEvent will create and
own the Clock instance. The Clock cannot be shutdown until Tomcat is shutdown.
The latest patch seems to be stopping the clock when a web app is undeployed.
That just won't work properly.
If log4j-core is in each web apps WEB-INF/lib directory then each app will have
its own Clock instance (and corresponding Thread if it is a CacnedClock), which
seems odd but I guess could work fine. In this case you need to stop the Clock
threads when each web app is undeployed.
These two use cases are expected to be "normal" deployment models and must both
work correctly. I just don't see how to reconcile between them.
> 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-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]
