[
https://issues.apache.org/jira/browse/LOG4J2-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14008332#comment-14008332
]
Remko Popma commented on LOG4J2-250:
------------------------------------
The Log4jLogEventBenchmark test mentioned in this JIRA is now checked in in
trunk under the log4j-perf module.
> (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
> Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> 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]
