You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2021/09/13 18:58:00 UTC

[jira] [Updated] (SOLR-15628) SolrException.log doesn't pass Throwable to Logger correctly

     [ https://issues.apache.org/jira/browse/SOLR-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris M. Hostetter updated SOLR-15628:
--------------------------------------
    Attachment: SOLR-15628.patch
      Assignee: Chris M. Hostetter
        Status: Open  (was: Open)

We should probably re-think the entire existence of {{SolrException.log()}} and the API design of {{SolrException.ignorePatterns}} – replacing all callers of {{SolrException.log()}} with {{logger.error()}} and use a new test-only log4j Filter/Appdener – but I don't really have a sense of exactly what that can/should look like just yet, and it would break back compat for any end-user solrj/solr tests that may depend on those methods.

----

In the mean time, we can "fix" the behavior of {{SolrException.log()}} in a way that doesn't pay the price of the "stringification" in non-test code (where there are no {{SolrException.ignorePatterns}} in a way that correctly passes the exception to the Logger -- see attached patch.

This should also improve the performance of {{SolrException.log()}} calls in non-test code using default solr log4j2.xml configuration, becuase of the AsyncLoggers (if/when the logger decides to produce the full stacktrace, it should be happening asynchronously).

The only (minor) downside i see to this patch is that now when we are running tests, the stack traces of the Throwables being logged by this code path can be converted to Strings twice: once for the regex check, and (now) once again by the Logger -- but AFAICT this doesn't noticeably slow down test times, because the tests also use AsyncLoggers

> SolrException.log doesn't pass Throwable to Logger correctly
> ------------------------------------------------------------
>
>                 Key: SOLR-15628
>                 URL: https://issues.apache.org/jira/browse/SOLR-15628
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Chris M. Hostetter
>            Assignee: Chris M. Hostetter
>            Priority: Major
>         Attachments: SOLR-15628.patch
>
>
> Having recently started using JSON based logging, I noticed that in many code paths situations where an error involving a "Throwable"  are logged isn't happening correctly (This is also noticeable using the default solr log4j2.xml configuration - but only subtly)
> The problem is that {{SolrException.log(...)}} has some very old (pre Solr 1.0, certainly pre SLF4j/Log4j) and hackish logic/code in it to support {{SolrException.ignorePatterns}} (which was designed for tests that wanted "quieter" output when they were intentionally triggering error situations.  This logic "stringifies" the entire Throwable (including stack trace) to test against any {{ignorePatterns}} that exist (even if there are no ignore patterns) before handing the resulting string off to the {{loggger.error(...)}} call -- _as a log message string_ - w/o the normal "structure" context of the original Throwable instance.
> This causes the full exception stack trace to come through as the log "message" -- even in log appenders that have been configured to only log partial stack trace details, or log them in special fields (ie: JSON Logging)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org