[
https://issues.apache.org/jira/browse/LOG4J2-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742986#comment-14742986
]
Ralph Goers edited comment on LOG4J2-1121 at 9/14/15 6:10 AM:
--------------------------------------------------------------
Well, I tried implementing the above but the performance is dramatically
slower. I'm not really sure why.
To be clear, I implemented my proposal, not yours. Yours should perform better.
No more time tonight.
Oh - the LoggerConfig can't point to itself. You will end up in an endless
loop. It needs to be null and set to the new Configuration when there is one.
However, I think this will still have a race condition if the log method is
already calling Appenders.
was (Author: [email protected]):
Well, I tried implementing the above but the performance is dramatically
slower. I'm not really sure why.
To be clear, I implemented my proposal, not yours. Yours should perform better.
No more time tonight.
> 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]
