[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743044#comment-14743044
]
Gary Gregory commented on LOG4J2-1121:
--------------------------------------
I am wondering if we can tie this in to a broader discussion related to
shutting down log4j.
In another thread, we talked about adding a LogManager.shutdown() API. But it
seems that in light of not loosing events on reconfigure it might be helpful to
consider the following:
- reconfigure does not loose events
- shutdown does not loose events
- a variant of shutdown, either with a force/immediate boolean or another name
like shutdownNow
The idea being that it would useful to distinguish in the code between shutting
down log4j vs. pausing it during a reconfigure.
When I shutdown with force/immediate, I might want to not wait until a timeout
on a broken socket appender for example for a log event that cannot be posted.
But, during a reconfigure, do I want to catch the socket timeout and not loose
the event? That sounds nasty... If after the reconfigure, the socket appender
works again, then I've effectively lost the event for that one appender;
granted the new configuration still has the same appender.
Tricky stuff...
> 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]
