[
https://issues.apache.org/jira/browse/LOG4J2-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15697097#comment-15697097
]
Remko Popma commented on LOG4J2-1718:
-------------------------------------
Converted to annotation in commit 3ee7d69.
> Introduce marker interface AsynchronouslyFormattable
> ----------------------------------------------------
>
> Key: LOG4J2-1718
> URL: https://issues.apache.org/jira/browse/LOG4J2-1718
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.7
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.8
>
>
> Logging mutable objects asynchronously always has the risk that the object is
> modified between the time the logger is called and the time the log message
> is formatted and written to disk.
> Log4j built-in Message implementation classes prevent this race condition in
> one of two ways:
> * Implement the {{ReusableMessage}} interface. Asynchronous logging
> components in log4j cooperate with ReusableMessages by copying their
> _content_ (formatted message, parameters) into the LogEvent rather than
> passing the Message instance itself. This ensures the formatted message will
> not change when the mutable object is modified.
> * Cache the formatted message when the {{getFormattedMessage}} method is
> called. Asynchronous logging components in log4j will call this method before
> passing the Message object to another thread. (See LOG4J2-763.) For example,
> FormattedMessage, LocalizedMessage, MessageFormatMessage, ObjectArrayMessage,
> ObjectMessage, ParameterizedMessage, SimpleMessage and StringFormattedMessage
> take this approach. Once initialized, {{getFormattedMessage}} returns the
> cached String, so changes to the mutable object will not impact the formatted
> message.
> For performance reasons, users can choose to format _all_ messages in the
> background by setting system property {{log4j.format.msg.async}} to true.
> (See LOG4J2-898.)
> Some messages do not capture mutable objects and are not at risk of the above
> race condition.
> This ticket proposes to introduce interface {{AsynchronouslyFormattable}} as
> a marker interface to signal to asynchronous logging components that messages
> of this type can safely be passed to a background thread without calling
> {{getFormattedMessage}} first.
> This benefits performance and avoids creating unnecessary (unused) objects.
> Candidates for implementing this interface are message implementations which
> do not cache anything in {{getFormattedMessage}}:
> * flow messages (SimpleEntryMessage and SimpleExitMessage)
> * MapMessage
> * StructuredDataMessage
> * ThreadDumpMessage (threads are cached in the constructor)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
