[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804948#comment-14804948
]
Remko Popma commented on LOG4J2-1121:
-------------------------------------
To be clear, I also firmly agree that reliability should come first. A
reconfiguration should not lose log events. But yes, at the same time I would
like to improve performance to below 1 microsecond per event (we're at
1.6us/event, Logback is at 1.2us/event).
With the Strategy I meant the Strategy design pattern: encapsulate the
mechanism used for reliable reconfiguration. One implementation (close to what
we do now) uses counters or locks. Another implementation does nothing.
Depending on whether monitorInterval is configured, Log4j selects the
appropriate Strategy implementation. During logging and during reconfiguration
we delegate to the Strategy instead locking or incrementing/checking counters
directly. That way users who don't need the reconfiguration can avoid the
performance impact they would otherwise incur with every event.
> LoggerConfig performance improvement: remove waitForCompletion and associated
> fields
> ------------------------------------------------------------------------------------
>
> Key: LOG4J2-1121
> URL: https://issues.apache.org/jira/browse/LOG4J2-1121
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.3
> Reporter: Remko Popma
>
> This ticket follows up on LOG4J2-1120. Out of the three changes identified in
> LOG4J2-1120, only two could be implemented in time for the 2.4 release.
> This ticket tracks the remaining work for the third change:
> * Since {{clearAppenders()}} is only called after all appenders have been
> stopped, {{waitForCompletion()}} may no longer be necessary (unless I am
> missing something here). If so, the {{shutdownLock}}, {{shutdown}} and
> {{counter}} fields can be removed. Not incrementing the atomic counters with
> every event in the hot path should give better performance.
> LOG4J2-1120 shows benchmark results that support this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
