Erick Erickson created SOLR-14460:
-------------------------------------
Summary: Fix side effect of logging call in
LogUpdateProcessorFactory
Key: SOLR-14460
URL: https://issues.apache.org/jira/browse/SOLR-14460
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: logging
Affects Versions: 7.5
Reporter: Erick Erickson
Assignee: Erick Erickson
This section of code:
{code:java}
if (log.isInfoEnabled()) {
log.info(getLogStringAndClearRspToLog());
}
if (log.isWarnEnabled() && slowUpdateThresholdMillis >= 0) {
final long elapsed = (long) req.getRequestTimer().getTime();
if (elapsed >= slowUpdateThresholdMillis) {
log.warn("slow: " + getLogStringAndClearRspToLog());
}
}
{code}
is wrong since getLogStringAndClearRspToLog() contains this bit:
{code:java}
rsp.getToLog().clear(); // make it so SolrCore.exec won't log this again
{code}
so the second call, if both are executed, has already cleared the rsp.toLog.
Besides it's poor form to have this kind of side-effect in a logging call.
I'll fix soon, now that I'm not in a panic thinking I introduced this with the
logging bits I did recently, this has been around since 7.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
