[
https://issues.apache.org/jira/browse/SOLR-16772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716455#comment-17716455
]
Chris M. Hostetter commented on SOLR-16772:
-------------------------------------------
I think a much cleaner way to deal with this would be to rip out the
{{StartupLoggingUtils.changeLogLevel(...)}} code, and instead rely on Log4j's
existing support to reference system property values in our default
{{log4j2.xml}} using fallback default values (which can differ between
references to the same property) ...
{code:java}
<AsyncLogger name="org.apache.hadoop" level="${solr.log.level:-warn}"/>
...
<AsyncRoot level="${solr.log.level:-info}">
{code}
...that would be a lot more transparent to users about when/why/how the logging
levels might not match what they see in the config, and would "do what people
expect" with _all_ the loggers if they set {{SOLR_LOG_LEVEL=ERROR}}
----
A few things to note:
* {{StartupLoggingUtils.changeLogLevel(...)}} is also used by SolrCLI, but for
effectively the same purpose to support {{-verbose}}
** This logic could be ripped out and replaced by referencing
{{solr.log.level}} in {{log4j2-console.xml}} and tweaking {{./bin/solr}} to set
that sysprop when calling {{run_tool}}
* {{solr.log.muteconsole}} / {{StartupLoggingUtils.muteConsole()}} is equally
suspect/confusing
** IIUC, we should be able to replace this with a {{SystemPropertyArbiter}} in
{{log4j2.xml}} config
** [https://logging.apache.org/log4j/2.x/manual/configuration.html#Arbiters]
> SOLR_LOG_LEVEL's effects are buggy/non-intuitive, should be handled by
> log4j2.xml
> ---------------------------------------------------------------------------------
>
> Key: SOLR-16772
> URL: https://issues.apache.org/jira/browse/SOLR-16772
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> The way that that {{SOLR_LOG_LEVEL}} (aka: {{solr.log.level}} sysprop) is
> implemented is that – if a value is specified – {{CoreContainerProvider}}
> calls {{StartupLoggingUtils.changeLogLevel(...)}} which (ultimately) calls
> log4j's
> {{{}LogManager.getContext(false).getConfiguration().getRootLogger().setLevel(...){}}}.
> But this has some weird and confusing effects in practice:
> * any logging before {{SolrDispatchFilter}} gets to this point will still
> happen – even if it violates the level specified
> * it only changes the level of the root logger. Any other loggers that are
> explicitly configured still use their configured level
> ** in the {{log4j2.xml}} file that we ship, we explicitly set levels for
> things like hadoop, zookeeper, LoggingInfoStream, HttpSolrCall, SlowRequest,
> jetty, etc..
> ** Which means even if you set {{SOLR_LOG_LEVEL=ERROR}} or
> {{SOLR_LOG_LEVEL=OFF}} you'll still get WARN (or in some cases INFO) level
> messages from those packages/classes
> * even if you run Solr with a custom {{log4j2.xml}} config, setting
> {{SOLR_LOG_LEVEL}} (or inheriting it from your env – maybe from a helm
> chart's default values.yaml) will cause your root logger's level might be
> overridden
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
