Remko Popma created LOG4J2-1718:
-----------------------------------
Summary: 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, StringFormattedMessage and
ThreadDumpMessage 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
