[logback-dev] [JIRA] Commented: (LBCLASSIC-234) CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide

[uri unger (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11900#action_11900 ] 

uri unger commented on LBCLASSIC-234:
-------------------------------------

hello there Ceki,

I have cloned this issue because we have stumbled into a very similar scenario in our production system.

we have a web app running inside tomcat that uses 4000 concurrent threads.
when we enable scanPeriod, we get around 6,000 transactions per second. if we simply disable file scanning entirely, we get 12,000 TPS.
granted, this is a real issue for us, and it forces us to use the non-scanning mode.

ofcourse, i have read the LBCLASSIC-154 bug, and currently i'm trying to regenerate our problem using your ReconfigurePerf test,.
however,  the mean while, i would sure like to hear your thoughts on this matter.

we use the latest logback (0.9.26).

thanks alot
uri at amobee

> 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
>
> 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