logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-1718) Introduce marker interface AsynchronouslyFormattable
Date Sun, 20 Nov 2016 15:56:00 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Remko Popma updated LOG4J2-1718:
--------------------------------
    Description: 
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)

  was:
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


> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message