[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743196#comment-14743196
]
Remko Popma commented on LOG4J2-1121:
-------------------------------------
I was thinking to call a separate helper method so there is no endless loop:
{code}
// initially delegate to self, reconfiguration swaps the delegate to the new
LoggerConfig
private volatile LoggerConfig delegate = this;
public void log(final LogEvent event) {
delegate.logDelegated(event);
}
private void logDelegated(final LogEvent event) {
if (!isFiltered(event)) { processLogEvent(event); }
}
{code}
However, you raise a painfully good point about the race condition. Solutions
like this will never be watertight. :-( Even doing this further downstream (in
AppenderControl or even in Appender), we cannot fully prevent the race
condition that occurs if the logging thread has executed past the guarding
volatile field but not yet delivered its payload when the appender is stopped.
I don't think a solution exists that covers all possible edge cases. I would
argue that a simple delay before stopping the appenders will take care of the
"normal" race condition.
{code}
// LoggerContext
private Configuration setConfiguration(final Configuration config) {
configLock.lock();
try {
...
config.start();
this.config = config;
updateLoggers();
if (prev != null) {
prev.removeListener(this);
// give threads that already entered the old config a chance to
finish up
Thread.sleep(GRACE_PERIOD); // e.g., 10 seconds?
prev.stop();
}
...
} finally {
configLock.unlock();
}
}
{code}
If a second reconfiguration starts before the first reconfiguration finishes,
the lock in LoggerContext.setConfiguration should prevent any issues AFAICS.
What is not covered is the case of an appender waiting in a blocking I/O
operation that takes longer than our GRACE_PERIOD. But is it possible for us to
guarantee Log4j won't lose log events in such a scenario?
> 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]
