[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742794#comment-14742794
]
Ralph Goers edited comment on LOG4J2-1121 at 9/14/15 2:13 AM:
--------------------------------------------------------------
Gary - I'm not OK. I think it really makes us look bad.
Remko - We wouldn't be using backup appenders. What would happen is that the
new configuration would be started and the loggers all updated. Then we would
go through the LoggerConfigs from the old configuration and add a reference to
appropriate LoggerConfig in the new Configuration. Then we would stop each
LoggerConfig. Then we would stop the appenders. But this could lead to
duplicate events if the new LoggerConfig sends the event to Appenders that were
already processed in the old LoggerConfig.
It seems to me a better approach is to keep the counters and modify them
slightly, along with the above.
1. In waitForCompletion change
counter.get() > 0
to
counter.compareAndSet(0, INT_MIN)
2. Change beforeLogEvent to
boolean beforeLogEvent() {
return counter.incrementAndGet() > 0;
}
3. In LoggerConfig log(Event) if beforeLogEvent returns false then delegate to
the LoggerConfig in the new Configuration.
4. In LoggerConfig override the stop method. Have it set a reference to the new
LoggerConfig and move the call to waitForCompletion to it.
5. In AbstractLogger call the LoggerConfig stop methods before stopping the
appenders.
was (Author: [email protected]):
Remko - We wouldn't be using backup appenders. What would happen is that the
new configuration would be started and the loggers all updated. Then we would
go through the LoggerConfigs from the old configuration and add a reference to
appropriate LoggerConfig in the new Configuration. Then we would stop each
LoggerConfig. Then we would stop the appenders. But this could lead to
duplicate events if the new LoggerConfig sends the event to Appenders that were
already processed in the old LoggerConfig.
It seems to me a better approach is to keep the counters and modify them
slightly, along with the above.
1. In waitForCompletion change
counter.get() > 0
to
counter.compareAndSet(0, INT_MIN)
2. Change beforeLogEvent to
boolean beforeLogEvent() {
return counter.incrementAndGet() > 0;
}
3. In LoggerConfig log(Event) if beforeLogEvent returns false then delegate to
the LoggerConfig in the new Configuration.
4. In LoggerConfig override the stop method. Have it set a reference to the new
LoggerConfig and move the call to waitForCompletion to it.
5. In AbstractLogger call the LoggerConfig stop methods before stopping the
appenders.
> 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]
