[
https://issues.apache.org/jira/browse/SOLR-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-18133:
-----------------------------------
Description:
Many log4j2.xml config files rely on the following pattern for "PatternLayout":
{code}
%maxLen{%d{yyyy-MM-dd HH:mm:ss.SSS} %-5p (%t)
[%notEmpty{c:%X{collection}}%notEmpty{ s:%X{shard}}%notEmpty{
r:%X{replica}}%notEmpty{ x:%X{core}}%notEmpty{ t:%X{trace_id}}] %c{1.}
%m%notEmpty{ =>%ex{short}}}{10240}%n
{code}
Of particular note is the "ex{short}" bit at the end of the pattern string -
this tells log4j2 to only print a "shortened" stacktrace of one or two lines
instead of the full thing.
While brevity is always appreciated, this cuts out too much useful information
and makes it more difficult to debug server behavior.
*NOTE:*
There's some uncertainty around when this behavior started. On one hand, I
don't recollect seeing this in currently released versions of Solr (e.g.
9.10.1). But on the other hand...patternLayout string has had "ex{short}"
since Erick Erickson's work on async logging back in 2019 (0de390 of
SOLR-12055).
I suspect (but haven't proved) that there was a bug in past log4j versions that
prevented us from getting the shortened exception behavior despite our config
requesting it. And that we only started seeing the shortened behavior
following a log4j upgrade somewhat recently.
In any case, I see the shorted stacktrace on 'main' as of 2/25.
was:
Many log4j2.xml config files rely on the following pattern for "PatternLayout":
{code}
%maxLen{%d{yyyy-MM-dd HH:mm:ss.SSS} %-5p (%t)
[%notEmpty{c:%X{collection}}%notEmpty{ s:%X{shard}}%notEmpty{
r:%X{replica}}%notEmpty{ x:%X{core}}%notEmpty{ t:%X{trace_id}}] %c{1.}
%m%notEmpty{ =>%ex{short}}}{10240}%n
{code}
Of particular note is the {{%ex{short}}} bit at the end of the pattern string -
this tells log4j2 to only print a "shortened" stacktrace of one or two lines
instead of the full thing.
While brevity is always appreciated, this cuts out too much useful information
and makes it more difficult to debug server behavior.
*NOTE:*
There's some uncertainty around when this behavior started. On one hand, I
don't recollect seeing this in currently released versions of Solr (e.g.
9.10.1). But on the other hand...patternLayout string has had "ex{short}"
since Erick Erickson's work on async logging back in 2019 (0de390 of
SOLR-12055).
I suspect (but haven't proved) that there was a bug in past log4j versions that
prevented us from getting the shortened exception behavior despite our config
requesting it. And that we only started seeing the shortened behavior
following a log4j upgrade somewhat recently.
In any case, I see the shorted stacktrace on 'main' as of 2/25.
> Solr should log full stacktraces rather than abbreviated ones
> -------------------------------------------------------------
>
> Key: SOLR-18133
> URL: https://issues.apache.org/jira/browse/SOLR-18133
> Project: Solr
> Issue Type: Bug
> Components: logging
> Affects Versions: main(11.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
>
> Many log4j2.xml config files rely on the following pattern for
> "PatternLayout":
> {code}
> %maxLen{%d{yyyy-MM-dd HH:mm:ss.SSS} %-5p (%t)
> [%notEmpty{c:%X{collection}}%notEmpty{ s:%X{shard}}%notEmpty{
> r:%X{replica}}%notEmpty{ x:%X{core}}%notEmpty{ t:%X{trace_id}}] %c{1.}
> %m%notEmpty{ =>%ex{short}}}{10240}%n
> {code}
> Of particular note is the "ex{short}" bit at the end of the pattern string -
> this tells log4j2 to only print a "shortened" stacktrace of one or two lines
> instead of the full thing.
> While brevity is always appreciated, this cuts out too much useful
> information and makes it more difficult to debug server behavior.
> *NOTE:*
> There's some uncertainty around when this behavior started. On one hand, I
> don't recollect seeing this in currently released versions of Solr (e.g.
> 9.10.1). But on the other hand...patternLayout string has had "ex{short}"
> since Erick Erickson's work on async logging back in 2019 (0de390 of
> SOLR-12055).
> I suspect (but haven't proved) that there was a bug in past log4j versions
> that prevented us from getting the shortened exception behavior despite our
> config requesting it. And that we only started seeing the shortened behavior
> following a log4j upgrade somewhat recently.
> In any case, I see the shorted stacktrace on 'main' as of 2/25.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
