[
https://issues.apache.org/jira/browse/SOLR-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101030#comment-17101030
]
Erick Erickson commented on SOLR-14460:
---------------------------------------
Hmmm, looking at this some more, it looks like the log should only be cleared
if it's been logged at least once. The code is still incorrect as it stands
since logging the slow query can be called after the rsp.toLog has been cleared
by the INFO level call first.
> 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
> Priority: Minor
>
> 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
