[jira] [Commented] (LOG4J2-578) JMX Memory Leak in Servlet Container

["Scott (JIRA)" <ji...@apache.org>]

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

Scott commented on LOG4J2-578:
------------------------------

Sorry [~remkop@yahoo.com] I have missed the email notifications on this issue until today.

To clarify my previous statements:
# My The memory leak persists if the servlet version is not set correctly.  If the servlet version is set correctly there is no leak but the logging context seems to be destroyed before the "contextDestroyed" application event is called.  I believe the desired behavior is the application has access to logging all the way from "contextInitialized" to "contextDestroyed" inclusive.
# Spring/my issue - I am not sure how to explicitly set the servlet version using spring with java annotations configuration.  It seems as though [spring 4.0|http://docs.spring.io/spring/docs/current/spring-framework-reference/html/new-in-4.0.html] is implying it will pick the version up based upon what is on the classpath but I am not seeing this behavior.

I will take a look with the updated code base.  Is the trunk build results pushed into maven central?

> JMX Memory Leak in Servlet Container
> ------------------------------------
>
>                 Key: LOG4J2-578
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-578
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0-rc1
>         Environment: Ubuntu 12.04
> Linux 3.2.0-58-generic x86_64 GNU/Linux
> 8 GB RAM
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
> JAVA_OPTS=-Xmx1024m -Dsun.net.inetaddr.ttl=60 -Dsun.net.inetaddr.negative.ttl=60 -Djava.net.preferIPv4Stack=true -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
>            Reporter: Scott
>            Assignee: Remko Popma
>            Priority: Critical
>              Labels: memory_leak
>
> If JMX is enabled in Log4j2 (it is by default) and a web application is unloaded then Log4j2 creates a memory leak. This can be observed by deploying a web application to tomcat7 and exercising the stop, undeploy, or redeploy actions. The "unloaded" terminology is meant to be generic across servlet containers in that any action which is designed to make the web application classes eligible for GC.  The memory leak is believed to be caused by log4j for the following reasons:
> 1)Heap Dump reveals the classloader instance responsible for the WAR plugin (for tomcat7 is of type {code}org.apache.catalina.loader.WebappClassLoader{code}) has 1 non weak/soft reference which is of type {code}org.apache.logging.log4j.core.jmx.LoggerContextAdmin{code} after the WAR has been stopped or undeployed.
> 2) Disabling JMX in Log4j2 (see [http://logging.apache.org/log4j/2.x/manual/jmx.html]) results in no memory leaks and all resources are GC as expected.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org