[ http://jira.qos.ch/browse/LBCLASSIC-253?page=com.atlassian.jira.plugin.syste... ] Thomas Becker edited comment on LBCLASSIC-253 at 3/1/11 4:34 PM: ----------------------------------------------------------------- FYI the issue here seems to be that the LogbackMDCAdapter is clearing the HashMap before calling copyOnInheritThreadLocal.remove(). The HashMap instance itself is shared with the parent thread since T childValue(T parentValue) is not overridden when the thread local is created. As far as I can tell, the clear() is unnecessary (and undesirable). was (Author: tbecker): FYI the issue here seems to be that the LogbackMDCAdapter is clearing the HashMap before calling copyOnInheritThreadLocal.remove(). The HashMap instance itself is shared with the parent thread since T childValue(T parentValue) is not overridden when the thread local is created.

MDC.clear() in child thread improperly affects parent. ------------------------------------------------------

Key: LBCLASSIC-253 URL: http://jira.qos.ch/browse/LBCLASSIC-253 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.28 Environment: JDK 1.6.0_21 Reporter: Thomas Becker Assignee: Logback dev list

I want to upgrade logback to 0.9.28 but one of my unit tests caught this bug in the LogbackMDCAdapter. Basically, if a child thread clears the MDC, the parent thread's copy is cleared as well. This simple unit test illustrates the problem. import org.junit.Test; import org.slf4j.MDC; /** * Demonstrates a bug in LogbackMDCAdapter. The clear() executed by the child thread should not affect the parent. */ public class MDCTest { @Test public void testBug() throws InterruptedException { MDC.put("foo", "bar"); assertEquals("bar", MDC.get("foo"));

Thread clearer = new Thread() { @Override public void run() { MDC.clear(); assertNull(MDC.get("foo")); } }; clearer.start(); clearer.join(); //Fails assertEquals("bar", MDC.get("foo")); } }

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

[ http://jira.qos.ch/browse/LBCLASSIC-253?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-253. ---------------------------------- Fix Version/s: 0.9.29 Resolution: Fixed A recent commit [1] fixes this problem as well as LBCLASSIC-254. [1] http://github.com/ceki/logback/commit/e068bd3b9754e8d6

MDC.clear() in child thread improperly affects parent. ------------------------------------------------------

Key: LBCLASSIC-253 URL: http://jira.qos.ch/browse/LBCLASSIC-253 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.28 Environment: JDK 1.6.0_21 Reporter: Tommy Becker Assignee: Ceki Gulcu Fix For: 0.9.29

I want to upgrade logback to 0.9.28 but one of my unit tests caught this bug in the LogbackMDCAdapter. Basically, if a child thread clears the MDC, the parent thread's copy is cleared as well. This simple unit test illustrates the problem. import org.junit.Test; import org.slf4j.MDC; /** * Demonstrates a bug in LogbackMDCAdapter. The clear() executed by the child thread should not affect the parent. */ public class MDCTest { @Test public void testBug() throws InterruptedException { MDC.put("foo", "bar"); assertEquals("bar", MDC.get("foo"));

Thread clearer = new Thread() { @Override public void run() { MDC.clear(); assertNull(MDC.get("foo")); } }; clearer.start(); clearer.join(); //Fails assertEquals("bar", MDC.get("foo")); } }

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