[jira] [Work logged] (LOG4J2-2399) Reusable Messages do not respect log4j.format.msg.async

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOG4J2-2399?focusedWorklogId=848200&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-848200 ]

ASF GitHub Bot logged work on LOG4J2-2399:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 01/Mar/23 07:13
            Start Date: 01/Mar/23 07:13
    Worklog Time Spent: 10m 
      Work Description: ppkarwasz commented on PR #208:
URL: https://github.com/apache/logging-log4j2/pull/208#issuecomment-1449466907

   This was closed automatically by Github because we renamed the `release-2.x` branch to `2.x`. Feel free to resubmit to the `2.x` branch.




Issue Time Tracking
-------------------

    Worklog Id:     (was: 848200)
    Time Spent: 20m  (was: 10m)

> 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
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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
(v8.20.10#820010)