You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Erick Erickson (Jira)" <ji...@apache.org> on 2020/05/06 12:41:00 UTC

[jira] [Created] (SOLR-14460) Fix side effect of logging call in LogUpdateProcessorFactory

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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org