[ https://issues.apache.org/jira/browse/SLING-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated SLING-3341: ----------------------------------- Description: Current way to configure Logback works like as below 1. Any change in config finally leads a call to org.apache.sling.commons.log.logback.internal.LogbackManager#configChanged 2. The config change is not done in concurrent way. A thread must acquire the {{resetLock}} to trigger Logback reset. If this lock cannot be acquired then it just sets a flag {{configChanged}} to true. The Logback reset job upon completion checks {{configChanged}} . if found to be true then it reschedules the job to load Logback again In current impl there is a small race condition where its possible that Logback reset job does not see the {{configChanged}} flag and hence Logback does not get reinitialized and is configured with stale config was: Current way to configure Logback works like as below # Any change in config finally leads a call to org.apache.sling.commons.log.logback.internal.LogbackManager#configChanged # The config change is not done in concurrent way. A thread must acquire the {{resetLock}} to trigger Logback reset. If this lock cannot be acquired then it just sets a flag {{configChanged}} to true. The Logback reset job upon completion checks {{configChanged}} . if found to be true then it reschedules the job to load Logback again In current impl there is a small race condition where its possible that Logback reset job does not see the {{configChanged}} flag and hence Logback does not get reinitialized and is configured with stale config > [logback] Race condition in configuring Logback > ----------------------------------------------- > > Key: SLING-3341 > URL: https://issues.apache.org/jira/browse/SLING-3341 > Project: Sling > Issue Type: Bug > Components: Commons > Affects Versions: Commons Log 4.0.0 > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra > > Current way to configure Logback works like as below > 1. Any change in config finally leads a call to > org.apache.sling.commons.log.logback.internal.LogbackManager#configChanged > 2. The config change is not done in concurrent way. A thread must acquire the > {{resetLock}} to trigger Logback reset. If this lock cannot be acquired then > it just sets a flag {{configChanged}} to true. The Logback reset job upon > completion checks {{configChanged}} . if found to be true then it reschedules > the job to load Logback again > In current impl there is a small race condition where its possible that > Logback reset job does not see the {{configChanged}} flag and hence Logback > does not get reinitialized and is configured with stale config -- This message was sent by Atlassian JIRA (v6.1.5#6160)