[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14791605#comment-14791605
]
Ralph Goers commented on LOG4J2-1121:
-------------------------------------
Scenario:
Thread 1 calls logMessage. The loggerConfig variable is set to
privateConfig.loggerConfig.
Thread 2 calls setConfiguration, which creates a new configuration and calls
updateLoggers. privateConfig now points to the new Configuration. The previous
configuration is stopped.
Thread 1 calls beforeLog but the loggerConfig is now invalid.
If beforeLog could return false if the counter is negative we could loop back
and get the loggerConfig again, which would now point to the new configuration.
This is almost the same as what I proposed before - getting a reference to the
new LoggerConfig. It is simpler to code but I am worried about what extra
overhead this might add.
> 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]
