[
https://issues.apache.org/jira/browse/LOG4J2-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573739#comment-16573739
]
ASF GitHub Bot commented on LOG4J2-2399:
----------------------------------------
Github user cakofony commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/205#discussion_r208699061
--- Diff:
log4j-api/src/main/java/org/apache/logging/log4j/message/ReusableParameterizedMessage.java
---
@@ -125,12 +123,23 @@ private void init(final String messagePattern, final
int argCount, final Object[
this.varargs = null;
this.messagePattern = messagePattern;
this.argCount = argCount;
- final int placeholderCount = count(messagePattern, indices);
- initThrowable(paramArray, argCount, placeholderCount);
- this.usedCount = Math.min(placeholderCount, argCount);
+
+ int usedParams = count(messagePattern, null);
+ if (usedParams < argCount && paramArray[argCount - 1] instanceof
Throwable) {
+ this.throwable = (Throwable) paramArray[argCount - 1];
+ } else {
+ this.throwable = null;
+ }
--- End diff --
I wonder if we should check `argCount > 0 && paramArray[argCount - 1]
instanceof Throwable` prior to invoking count? Could be worth a benchmark,
either way one iteration over a format string isn't very expensive.
> 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)
