[
https://issues.apache.org/jira/browse/LOG4J2-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14332144#comment-14332144
]
Remko Popma commented on LOG4J2-938:
------------------------------------
Mauro,
Thanks for the clarification. I understand the reasoning behind the patch now.
There are three problems the patch is addressing:
# The Executor must use a daemon thread or the VM will not shut down on Tomcat
stop
# Restarting the webapp without stopping the Executor thread causes a memory
leak
# depending on the logging configuration, a webapp can still invoke Log4j2
after the logger context has been shut down
I've gone ahead and made the Executor a daemon thread for now (commit e27c5b5
in git master).
I would like to think a little more about problem 2. Note that another option
is to use a {{null}} Executor: this will cause notifications to be sent out in
the _calling_ thread instead of a background thread. This is an alternative
solution that will solve both problem 1 (the VM not shutting down) and problem
2 (the memory leak). I am not sure about the performance impact, however, it
may be that there is very little status logging going on during normal
operation, so performance impact is negligible. This may be the simplest
solution.
I would like to understand problem 3 better. What configuration causes this and
which configuration avoids this behaviour?
> 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]
