[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742634#comment-14742634
]
Ralph Goers commented on LOG4J2-1121:
-------------------------------------
You are correct that even with the way it was done previously there was a
window where an error could occur.
FileConfiguratonMonitor already kicks off the reconfiguration on a separate
thread, so there is no need for another one. However, should another
reconfiguration take place it would be a problem if it was to start before the
first reconfiguration finishes, so there would have to be some signaling there.
But that wouldn't have any impact on logging performance. Of course, even
putting a wait in may not prevent problems if there is some appender in a wait
for a socket or something similar.
Would it make sense for the old LoggerConfig to reference the appropriate new
LoggerConfig and then use it if the current LoggerConfig is marked as stopping?
> 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]
