[ 
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14791380#comment-14791380
 ] 

Remko Popma commented on LOG4J2-1121:
-------------------------------------

It may be possible to fix the race condition in the counter/waitForCompletion 
design by incrementing the counter before calling LoggerConfig.log:

{code}
// Logger, similar change needed in AsyncLogger
public void logMessage(final String fqcn, final Level level, final Marker 
marker, 
        final Message message, final Throwable t) {
    final Message msg = message == null ? new SimpleMessage(Strings.EMPTY) : 
message;
    config.config.getConfigurationMonitor().checkConfiguration();

    // The above line may trigger a reconfig, so load volatile field again. 
    // Subtle point: hoist volatile field into local var, since we will use it 
twice. 
    LoggerConfig loggerConfig = privateConfig.loggerConfig;

    // increment counter first
    loggerConfig.beforeLog();

    // then call log method
    loggerConfig.log(getName(), fqcn, marker, level, msg, t);
{code}

Then of course we need to fix AbstractConfiguration to call clearAppenders 
before it stops the Appenders. 

I think this should work (prevent log events getting dropped with a reconfig).
What I don't like though is how this mechanism is spread out over several 
classes and depends on all participants doing the right thing in the right 
order...

> 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]

Reply via email to