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

Gary Gregory commented on LOG4J2-938:
-------------------------------------

Thank you for your report. Patches are welcome...

> org.apache.logging.log4j.core.jmx.Server never shuts down the ExecutorService 
> it creates
> ----------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-938
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-938
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 2.1
>            Reporter: Mauro Molinari
>            Priority: Critical
>
> The class {{org.apache.logging.log4j.core.jmx.Server}} creates an 
> {{ExecutorService}} at construction time and and stores it as an instance 
> variable of type {{Executor}} (named {{executor}}).
> This executor service is never shut down (I guess the {{unregisterMBeans()}} 
> methods may be good candidates, with some care for 
> {{unregisterMBeans(MBeanServer)}} which performs unregistration only for a 
> single {{MBeanServer}}). This causes a memory leak if Log4j is used in a web 
> application (under Tomcat, for instance) and the JMX services have been used 
> (i.e.: the {{Server}} class has been instantiated).
> But even worse, what I'm observing is that a notification Job may be 
> submitted to that executor by 
> {{javax.management.NotificationBroadcasterSupport.sendNotification(Notification)}},
>  invoked by 
> {{org.apache.logging.log4j.core.jmx.StatusLoggerAdmin.log(StatusData)}} in 
> certain circumstances exactly during Tomcat shutdown process: since the 
> executor is using non-daemon threads to execute tasks, this eventually 
> prevents the application server to shutdown (I have to kill it).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to