[
https://issues.apache.org/jira/browse/LOG4J2-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574963#comment-16574963
]
ASF GitHub Bot commented on LOG4J2-2399:
----------------------------------------
GitHub user bjlaub opened a pull request:
https://github.com/apache/logging-log4j2/pull/208
[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.
---
Re-opened from #205
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/208.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 #208
----
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.
commit e015b4aab968a2aa20dc9a40082d98cfe63528cb
Author: Brian Laub <bjlaub@...>
Date: 2018-08-09T13:54:31Z
split ReusableParameterizedMessage's formatter into separate class
commit fc8ed21311d3a428b5a673a1b289ea2624e60cdb
Author: Brian Laub <bjlaub@...>
Date: 2018-08-09T14:59:19Z
dont reformat when events are copied to async ringbuffer and are already
formatted
also fix an issue with nested logging that clobbered already-computed
indices
----
> 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)
