[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742864#comment-14742864
]
Remko Popma commented on LOG4J2-1121:
-------------------------------------
Ralph, I have no objection to making this a blocker.
I understand that you want to do this at the LoggerConfig level, not with
backup Appenders. I agree that simplifies things.
There may be a way to avoid the need for the counters/waitForCompletion
protocol: With your proposal, each LoggerConfig has a reference to the new
LoggerConfig, but it won't delegate to this reference until it detects that a
reconfiguration took place. Detecting this requires counters and a lock.
Can we flip this around and _always_ delegate to this reference? Initially the
delegate simply points to itself, but a reconfiguration causes it to be
replaced with the new LoggerConfig. (Essentially similar to the PrivateConfig
volatile field in Logger, which gets swapped in LoggerContext.updateLoggers.)
Overriding LoggerConfig stop would work as you describe.
Since the reference gets atomically replaced, we no longer need to detect a
reconfiguration, and so the counters and the lock are no longer needed. This
seems more robust as well as more efficient.
Thoughts?
> 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]
