[
https://issues.apache.org/jira/browse/SOLR-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-14460.
-----------------------------------
Resolution: Invalid
So I took a nap and things became clearer. The intent of response.toLog is to
get published once, and that's what happens.
I was all panicky fearing I'd messed up in the recent mass changes I did for
LUCENE-7788, but this has been here all along.
> 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
