Chris M. Hostetter created SOLR-16772:
-----------------------------------------
Summary: 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
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
