[
https://issues.apache.org/jira/browse/LOG4J2-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344177#comment-14344177
]
Remko Popma commented on LOG4J2-945:
------------------------------------
Two things to consider: how many listeners are there, and how many status
events are generated by log4j?
By default, there are only two listeners: one for the JMX StatusAdmin MBean,
and one that logs to the console (hooked in when the configuration is
initializing).
As for the number of status log events, my impression is that the vast majority
is generated during initialization (and perhaps shutdown). Once log4j is up and
running, status log events are exceedingly rare. Examples I can think of are
log file rollover and re-initialization because a monitored config file has
been modified. (Please let me know if there are log4j components that generate
many status log events during normal operation.)
Given that there are only a few events and a few listeners, I would not mind
getting rid of the listenersLevel altogether and simply asking each listener if
they are interested in this status log event. We can create a JMH performance
test to verify the performance impact.
Background: I documented the system properties status logging for the 2.2
release and it was not easy to understand how all the different pieces fit
together. I would prefer to simplify the design if possible.
> Reconfiguring statusLogger to a higher level doesn't work correctly
> -------------------------------------------------------------------
>
> Key: LOG4J2-945
> URL: https://issues.apache.org/jira/browse/LOG4J2-945
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1
> Reporter: Stefan Wehner
> Priority: Minor
> Attachments: callback_on_reconfig.patch, remove_listeners_level.patch
>
>
> When reconfiguring log4j and changing the level of the status logger to a
> higher level - e.g. from WARN to DEBUG, it doesn't work correctly.
> Steps to reproduce:
> # Configure from log4j2.xml containing:
> {code}
> <Configuration status="WARN" monitorInterval="5">
> ...
> {code}
> # With the app running, change status to a higher level:
> {code}
> <Configuration status="DEBUG" monitorInterval="5">
> ...
> {code}
> # Observe that the log config is reloaded, but no debug messages for the
> status logger appear.
> From what I've seen this is because the {{StatusConfiguration.initialize()}}
> reconfigures the listeners' level
> [StatusConfig:193|https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/config/status/StatusConfiguration.java;h=4d2ee51b4cf5dcb6f62029fe307093a759bf0af7;hb=HEAD#l193]
> But it doesn't update the {{listenersLevel}} field that the {{StatusLogger}}
> uses for checking if the logger is enabled (I understand this should be the
> maximum of all of the listener's levels)
> [StatusLogger:273|https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-api/src/main/java/org/apache/logging/log4j/status/StatusLogger.java;h=39d447d9793ca08a7d86b9eaaf6ef3dd406cf9a2;hb=HEAD#l273]
> So in this case the listenersLevel is still at WARN, even though the console
> listener has a DEBUG level, and all the log messages are ignored because
> isEnabled(DEBUG) returns false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
