[
https://issues.apache.org/jira/browse/LOG4J2-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574969#comment-16574969
]
ASF GitHub Bot commented on LOG4J2-2399:
----------------------------------------
Github user bjlaub commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/205#discussion_r208965737
--- Diff:
log4j-api/src/main/java/org/apache/logging/log4j/message/ReusableParameterizedMessage.java
---
@@ -355,4 +352,35 @@ public void clear() { // LOG4J2-1583
messagePattern = null;
throwable = null;
}
+
+ @Override
+ public MessageContentFormatter getMessageContentFormatter() {
+ return formatter;
+ }
+
+ private static final MessageContentFormatter formatter = new
MessageContentFormatter() {
+ private final ThreadLocal<int[]> indices = new ThreadLocal<>();
--- End diff --
see
https://github.com/apache/logging-log4j2/pull/208/commits/fc8ed21311d3a428b5a673a1b289ea2624e60cdb
in #208
> 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)
