[
https://issues.apache.org/jira/browse/LOG4J2-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-250:
-------------------------------
Description:
Background: during investigation of LOG4J2-245, several people raised
performance concerns regarding ThrowableProxy. This issue is to separate that
concern so that LOG4J2-245 can focus on resolving the EmptyStackException.
ThrowableProxy does quite a bit of expensive-looking work to find the JAR file
or directory where the class that threw the exception is located. This work is
done for every event that contains an exception.
However, this information is only used when the configuration contains either a
RootThrowablePattern {"rEx", "rThrowable", "rException" } or an
ExtendedThrowablePattern {"xEx", "xThrowable", "xException" } or when the
LogEvent is serialized.
I propose to change the Log4jLogEvent implementation: instead of
unconditionally creating a ThrowableProxy object every time a log event
contains an exception, only wrap this exception in a ThrowableProxy when either:
* the {{getThrownProxy()}} method is called
* the log event is serialized
For reference, similar work has already been done on
{{o.a.l.l.core.async.RingBufferLogEvent}}.
was:
Background: during investigation of LOG4J2-245, several people raised
performance concerns regarding ThrowableProxy. This issue is to separate that
concern so that LOG4J2-245 can focus on resolving the EmptyStackException.
ThrowableProxy does quite a bit of expensive-looking work to find the JAR file
or directory where the class that threw the exception is located. This work is
done for every event that contains an exception.
However, this information is only used when the configuration contains either a
RootThrowablePattern {"rEx", "rThrowable", "rException" } or an
ExtendedThrowablePattern {"xEx", "xThrowable", "xException" }.
This JIRA is to analyse the performance cost of constructing a ThrowableProxy
and (if it is significant) investigate ways to make construction optional based
on the configuration. That is, only construct ThrowableProxy if the
configuration contains a pattern that will use this information.
> (TBD) Refactor Log4jLogEvent to lazily create ThrowableProxy
> ------------------------------------------------------------
>
> Key: LOG4J2-250
> URL: https://issues.apache.org/jira/browse/LOG4J2-250
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta5
> Reporter: Remko Popma
>
> Background: during investigation of LOG4J2-245, several people raised
> performance concerns regarding ThrowableProxy. This issue is to separate that
> concern so that LOG4J2-245 can focus on resolving the EmptyStackException.
> ThrowableProxy does quite a bit of expensive-looking work to find the JAR
> file or directory where the class that threw the exception is located. This
> work is done for every event that contains an exception.
> However, this information is only used when the configuration contains either
> a RootThrowablePattern {"rEx", "rThrowable", "rException" } or an
> ExtendedThrowablePattern {"xEx", "xThrowable", "xException" } or when the
> LogEvent is serialized.
> I propose to change the Log4jLogEvent implementation: instead of
> unconditionally creating a ThrowableProxy object every time a log event
> contains an exception, only wrap this exception in a ThrowableProxy when
> either:
> * the {{getThrownProxy()}} method is called
> * the log event is serialized
> For reference, similar work has already been done on
> {{o.a.l.l.core.async.RingBufferLogEvent}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
