logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-819) PermGen OutOfMemoryError when reloading webapp on Tomcat 6
Date Fri, 12 Sep 2014 14:51:33 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131604#comment-14131604
] 

Remko Popma edited comment on LOG4J2-819 at 9/12/14 2:51 PM:
-------------------------------------------------------------

By the way, why use a boolean flag? Isn't it simpler to just call {{updaterThread.interrupt();}}
from the clock's stop() method, and change the run() method to {{while (!interrupted()) \{...\}}}.
In general the built-in interrupt() is better than a custom stop flag because it allows the
thread to return early from its call to sleep() when interrupted. The biggest advantage in
this case is that we don't need to build infrastructure to maintain the boolean anymore, so
no need for the StopFlagThread any more. (The Thread.interrupt() method is not deprecated
like the Thread.stop(), suspend() and resume() methods.)

That said, I still don't like having a public {{Clock.stop() method}}. This unloads the gun
for web apps (so they can no longer shoot themselves in the foot even if they try), but also
hands out the gun to everyone else so they can shoot themselves (by stopping the clock prematurely)...
:-( 


was (Author: remkop@yahoo.com):
By the way, why do you need a boolean flag? Isn't it simpler to just call {{updaterThread.interrupt();}}
from the clock's stop() method, and change the run() method to {{while (!interrupted()) \{...\}}}.
The sleep time in this case is only one millisecond, but in general interrupt is better than
a stop flag because it allows the thread to detect that it was stopped and return early from
its call to sleep(). The biggest advantage in this case is that you don't need to build infrastructure
to maintain the boolean anymore, so no need for the StopFlagThread any more. (The Thread.interrupt()
method is not deprecated like the Thread.stop(), suspend() and resume() methods.)

That said, I still don't like having a public {{Clock.stop() method}}. This unloads the gun
for web apps (so they can no longer shoot themselves in the foot even if they try), but also
hands out the gun to everyone else so they can shoot themselves (by stopping the clock prematurely)...
:-( 

> 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-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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message