[
https://issues.apache.org/jira/browse/LOG4J2-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573639#comment-16573639
]
ASF GitHub Bot commented on LOG4J2-2399:
----------------------------------------
GitHub user bjlaub opened a pull request:
https://github.com/apache/logging-log4j2/pull/205
[LOG4J2-2399] support for async formatting on reusable messages
Adds support for deferring message content formatting on certain
ReusableMessage implementations to a background thread when async
logging is enabled. This change adds the ability for log events to
retain an instance of a formatter for a message so that the message
content can be formatted later, after the message has already been
recycled.
This is an effort to optimize performance for use cases where formatting
on the logging thread is unnecessary or undesired.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bjlaub/logging-log4j2
async-background-formatting
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/logging-log4j2/pull/205.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #205
----
commit ddae40953cfe24232f58f23e90a417623a260853
Author: Brian Laub <bjlaub@...>
Date: 2018-08-08T16:13:35Z
[LOG4J2-2399] support for async formatting on reusable messages
Adds support for deferring message content formatting on certain
ReusableMessage implementations to a background thread when async
logging is enabled. This change adds the ability for log events to
retain an instance of a formatter for a message so that the message
content can be formatted later, after the message has already been
recycled.
This is an effort to optimize performance for use cases where formatting
on the logging thread is unnecessary or undesired.
----
> Reusable Messages do not respect log4j.format.msg.async
> -------------------------------------------------------
>
> Key: LOG4J2-2399
> URL: https://issues.apache.org/jira/browse/LOG4J2-2399
> Project: Log4j 2
> Issue Type: Task
> Components: Core
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
>
> Setting "log4j.format.msg.async" applies only to messages that do not
> implement ReusableMessage.
> On applications using asynchronous logging with message formatting in the
> background there is a measurable performance cost to using
> ReusableParameterizedMessages instead of ParameterizedMessages due to
> formatting on the application thread
> (MutableLogEvent/RingBufferLogEvent.setMessage).
> I have a custom layout which does not log formatted messages in most cases,
> but the format string and parameter values separately in order to analyze
> values logged over time bucketed by logger name and format string. In this
> case the formatting is unnecessary work. It is possible to implement a custom
> message factory which doesn't format message data, however that would break
> the ability to add a standard pattern layout in addition to the custom
> formatter.
> h2. Proposed Design
> Our reusable events (MutableLogEvent and RingBufferLogEvent) currently
> capture most of the required information, the format string and parameter
> array, but are missing a bit of context for how the original message
> implementation would format that data.
> ReusableMessage implementations may optionally extend
> "MessageContentFormatterProvider"
> {code:java}
> interface MessageContentFormatterProvider {
> MessageContentFormatter getMessageContentFormatter();
> }{code}
> Where MessageContentFormatter takes the form:
> {code:java}
> interface MessageContentFormatter {
> void appendTo(StringBuilder dest, String format, Object[] params, short
> paramCount);
> }{code}
> Reusable log event implementations will be updated to hold a reference to the
> content formatter (instead of formatting to the local event buffer) when
> asynchronous formatting is enabled _and_ the message is an instance of
> MessageContentFormatterProvider.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
