[
https://issues.apache.org/jira/browse/SOLR-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568049#comment-14568049
]
Hoss Man commented on SOLR-7615:
--------------------------------
bq. ... but it's pretty annoying when you go down to TRACE or DEBUG and
actually lose logging. ...
Whoa ... wait a minute -- that doesn't sound right at all. Are you sure the
problem you're remembering having is the same code being discussed in this
issue?
The optimization we're discussing is based on this line of code...
{code}
return LogUpdateProcessor.log.isInfoEnabled() ? new LogUpdateProcessor(req,
rsp, this, next) : null;
{code}
Logger.isInfoEnabled() does *NOT* return "false" for TRACE and DEBUG - it
returns true as long as the effective log level is _at least_ INFO -- you can
confirm this with something simple like...
{code}
public void testLoggerLevelSanity() throws Exception { // nocommit
org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger("whatever");
org.apache.log4j.LogManager.getRootLogger().setLevel(org.apache.log4j.Level.TRACE);
assertTrue(log.isDebugEnabled());
org.apache.log4j.LogManager.getRootLogger().setLevel(org.apache.log4j.Level.WARN);
assertFalse(log.isDebugEnabled());
}
{code}
...the fundemental issue here is that the changes added by SOLR-6650 cause
LogUpdateProcessor to be useful in some configurations even if the level is
only WARN, and not INFO - yet the Factory will currently not produce a
LogUpdateProcesssor in this situation -- ie: the changes made in SOLR-6650 did
not take into consideration the existing optimization, nor test for the
situation where the Logger was configured with a Level of WARN or ERROR
> Slow update requests not logged at WARN due to how LogUpdateProcessor's are
> created
> -----------------------------------------------------------------------------------
>
> Key: SOLR-7615
> URL: https://issues.apache.org/jira/browse/SOLR-7615
> Project: Solr
> Issue Type: Bug
> Reporter: Timothy Potter
> Assignee: Timothy Potter
> Priority: Minor
>
> In SOLR-6650, we introduced the ability to only have slow update and query
> requests get logged as warnings. However, when tracking down the cause of
> SOLR-7603, we discovered that the LogUpdateProcessor is only included in the
> chain if the log has INFO enabled, thus rendering the solution provided by
> SOLR-6650 useless for update requests (queries still work though).
> Thus, we need to fix how LogUpdateProcessor is created if the user has
> configured slowUpdateThresholdMillis > 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
