[
https://issues.apache.org/jira/browse/LOG4J2-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14332164#comment-14332164
]
Mauro Molinari commented on LOG4J2-938:
---------------------------------------
Hi Remko,
solving problem 2 in any case would solve problem 1, because if the
ExecutorService is properly shut down, it won't prevent the VM to cleanly shut
down, hence forcing it to use a daemon thread becomes almost useless.
Secondly, I also thought that letting Log4j2 use a {{null}} executor to let JMX
notifications being synchronous would have been the simplest solution: after
all, while debugging, I saw that other two libraries I'm using (HikariCP and
EclipseLink) are doing it this way. However, in my patch I followed the idea to
keep the asynchronous execution because I thought this was done on purpose in
Log4j2 for performance reasons.
Problem 3 happens whenever you use Log4j (either directly or indirectly,
through a higher level logging abstraction, like Slf4j or Commons Logging) in a
web application where you have other Servlet listeners that use logging (for
instance in their own contextDestroyed receiver method) after the Log4j logger
context have been shut down. In fact, AFAIK, there's no way to force a Servlet
3.1 environment to execute the
{{Log4jServletContextListener.contextDestroyed(ServletContextEvent)}} as the
very last one. Correct me if I'm wrong.
Your proposed solution is OK for me, although in principle I'm not keen on
doing different things in different environments unless strictly necessary. In
any case, isn't there a way to detect if we're in a web application by taking
advantage of the existence of {{Log4jServletContextListener}} or something like
that, instead of merely trying to detect if {{Servlet}} class in on the
classpath?
> 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
> Attachments: LOG4J2-938.patch
>
>
> 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]
