[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804410#comment-14804410
]
Remko Popma edited comment on LOG4J2-1121 at 9/18/15 4:29 AM:
--------------------------------------------------------------
Some thoughts:
1. Unconditional wait drawbacks: delaying a shutdown may be less desirable. Is
that the concern? I cannot see any drawbacks for reconfig, although as you
said, some signaling is required to ensure the next reconfig doesn't start
until the previous one successfully called updateLoggers. So I don't understand
your reluctance yet.
2. I wonder how performance could be so bad with your proposal to let beforeLog
return false if the counter is negative. Branch prediction should make the "if"
hardly noticeable... Can I see the code?
3. Locking: wow, you're reaching for the heavy artillery here. Which part of
the code do you want to put a lock around?
4. At work I never use monitorInterval. If the performance impact is going to
be high, then perhaps we should introduce a Strategy for this so that only
users who configured monitorInterval pay the performance price.
was (Author: [email protected]):
Unconditional wait drawbacks: delaying a shutdown may be less desirable. Is
that the concern? I cannot see any drawbacks for reconfig, although as you
said, some signaling is required to ensure the next reconfig doesn't start
until the previous one successfully called updateLoggers. So I don't understand
your reluctance yet.
I wonder how performance could be so bad with your proposal to let beforeLog
return false if the counter is negative. Branch prediction should make the "if"
hardly noticeable... Can I see the code?
Locking: wow, you're reaching for the heavy artillery here. Which part of the
code do you want to put a lock around?
At work I never use monitorInterval. If the performance impact is going to be
high, then perhaps we should introduce a Strategy for this so that only users
who configured monitorInterval pay the performance price.
> 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]
