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

Ralph Goers (JIRA) noreply-jira at qos.ch
Tue Nov 23 21:19:51 CET 2010


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

Ralph Goers commented on LBCLASSIC-234:
---------------------------------------

One of the design issues in this was how to use threads.  Managing threads has proven to be troublesome and is something the design of logback has avoided doing. I say this because an alternative approach to this is to use a servlet filter to create a thread that periodically determines if a reconfigure is necessary. This removes the bottleneck you are seeing because scanning will be disabled during normal Logback processing. However, because it is a servlet filter it can't be configured by logback.

The projects I work with all use this technique instead of the turbo filter.

I should also point out that while reconfiguration is taking place logging some logging events will be lost or possibly incorrectly handled. Reconfiguration stops all appenders and filters (but does not remove loggers added by the previous configuration) and then runs through the new configuration enabling filters and appenders as they are encountered.

> 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

        


More information about the logback-dev mailing list