[
http://jira.qos.ch/browse/LBCLASSIC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ceki Gulcu closed LBCLASSIC-153.
--------------------------------
Resolution: Cannot Reproduce
Hello,
I have tried to reproduce this bug by creating a relevant test case, called
ReconfigurePerf, part of the ch.qos.logback.classic.turbo package (in
src/test) and measuring its performance on 4 core CPU with 5 threads. JProfiler
showed that only a marginal percentage of CPU was spent in
ReconfigureOnChangeFilter's decide method. Using Yourkit yielded similar
results.
So, either
1) ReconfigurePerf is non-representative
2) I misused the profiler
3) your tests are non-representative
In the mean-time I am marking this bug as "Cannot reproduce". If after
profiling ReconfigurePerf you obtain a different result, or you detect an error
in the test, do not hesitate to reopen this report.
> Excessive synchronization in ReconfigureOnChangeFilter.decide
> -------------------------------------------------------------
>
> Key: LBCLASSIC-153
> URL: http://jira.qos.ch/browse/LBCLASSIC-153
> Project: logback-classic
> Issue Type: Bug
> Affects Versions: 0.917
> Reporter: Anders Wallgren
> Assignee: Ceki Gulcu
> Attachments: screenshot-1.jpg
>
>
> The synchronization in ReconfigureOnChangeFilter.decide hurts scalability.
> It seems unnecessary to serialize the code in changeDetected -- it should be
> possible to use atomic updates of nextCheck and lastModified and only
> serialize the actual reconfiguration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://qos.ch/mailman/listinfo/logback-dev
