[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742750#comment-14742750
]
Remko Popma edited comment on LOG4J2-1121 at 9/14/15 12:26 AM:
---------------------------------------------------------------
Yes, that is a very good idea!
Let me see if I understand you correctly. Conceptually, for every AppenderRef
(or AppenderControl, somewhere in the relation between a LoggerConfig and an
Appender), there would be two Appenders: the "main" appender (the configured
appender), and a backup one.
If the main Appender is not in a STARTED state, the backup one is used. The
invariant we have to protect is that at least one of those most always be in a
STARTED state.
In a shutdown scenario, we could set a NOP appender that discards events. (I'm
open for better ideas.)
In a reconfiguration scenario, the happy case is where the new configuration
has an ApoenderRef for all of their refs in the old configuration. (No
AppenderRefs were deleted or renamed.)
In the unhappy case where the new configuration does not have a match for each
AppenderRef in the old configuration, what do we do? One idea is to provide a
default backup appender (logging to a file in a known location). Or again, use
a NOP appender that discards events (emitting a status warning perhaps).
was (Author: [email protected]):
Yes, that is a very good idea!
Let me see if I understand you correctly. Conceptually, for every AppenderRef
(or AppenderControl, somewhere in the relation between a LoggerConfig and an
Appender), there would be two Appenders: the "main" appender (the configured
appender), and a backup one.
If the main Appender is being shut down, the backup one is used. The invariant
we have to protect is that at least one of those most always be in a STARTED
state.
In a shutdown scenario, we could set a NOP appender that discards events. (I'm
open for better ideas.)
In a reconfiguration scenario, the happy case is where the new configuration
has an ApoenderRef for all of their refs in the old configuration. (No
AppenderRefs were deleted or renamed.)
In the unhappy case where the new configuration does not have a match for each
AppenderRef in the old configuration, what do we do? One idea is to provide a
default backup appender (logging to a file in a known location). Or again, use
a NOP appender that discards events (emitting a status warning perhaps).
> 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]
