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