[
https://issues.apache.org/jira/browse/LOG4J2-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15682334#comment-15682334
]
Remko Popma commented on LOG4J2-1718:
-------------------------------------
To be honest, I hadn't thought of it... :-)
Annotation seems faster, so I'll change it:
{code}
Benchmark Mode Samples
Score Score error Units
o.a.l.l.p.j.AnnotationVsMarkerInterface.annotation sample 99384
26.760 1.380 ns/op
o.a.l.l.p.j.AnnotationVsMarkerInterface.markerInterface sample 149745
67.403 1.430 ns/op
{code}
Benchmark code:
{code}
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@State(Scope.Benchmark)
public class AnnotationVsMarkerInterface {
private final SortedArrayStringMap map = new SortedArrayStringMap();
@Benchmark
@BenchmarkMode(Mode.SampleTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public Object annotation() {
return map.getClass().isAnnotationPresent(PerformanceSensitive.class);
}
@Benchmark
@BenchmarkMode(Mode.SampleTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public boolean markerInterface() {
return map instanceof StringBuilderFormattable;
}
}
{code}
> 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: [email protected]
For additional commands, e-mail: [email protected]
