[ http://jira.qos.ch/browse/LBCLASSIC-234?page=com.atlassian.jira.plugin.syste... ] uri unger commented on LBCLASSIC-234: ------------------------------------- Ceki, I can not easily change that line, re-package logback and our application, redeploy our application and re-run a full performance test. It is quite complex. However, I did try to rerun ReconfigurePerf after making your suggested change; and indeed the maximal thread contention time droped to10-12ms (instead of 200+ ms). Still, I think that using a simple scheduled config file check (using java's ScheduledThreadPoolExecutor for example) is a much better solution that would remove the synchronization penalty almost entirely. Are you considering using such a solution? Ralph, We are aware that we can turn off scanning in logback and implement it ourselves using our own thread. However, I'm sure that any sensible user of logback would prefer to have this functionality built-in without having to resort to in-house workarounds. uri
CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide --------------------------------------------------------------------
Key: LBCLASSIC-234 URL: http://jira.qos.ch/browse/LBCLASSIC-234 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Reporter: uri unger Assignee: Ceki Gulcu Priority: Critical 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