[
https://issues.apache.org/jira/browse/LOG4J2-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574970#comment-16574970
]
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_r208965807
--- Diff:
log4j-core/src/main/java/org/apache/logging/log4j/core/impl/MutableLogEvent.java
---
@@ -204,15 +206,19 @@ public void setLoggerName(final String loggerName) {
@Override
public Message getMessage() {
if (message == null) {
- return messageText == null ? EMPTY : this;
+ return (messageText == null && messageContentFormatter ==
null) ? EMPTY : this;
}
return message;
}
public void setMessage(final Message msg) {
if (msg instanceof ReusableMessage) {
final ReusableMessage reusable = (ReusableMessage) msg;
- reusable.formatTo(getMessageTextForWriting());
+ if (Constants.FORMAT_MESSAGES_IN_BACKGROUND && msg instanceof
MessageContentFormatterProvider) {
+ this.messageContentFormatter =
((MessageContentFormatterProvider) msg).getMessageContentFormatter();
--- 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)
