[ http://jira.qos.ch/browse/LBCLASSIC-253?page=com.atlassian.jira.plugin.syste... ] Thomas Becker commented on LBCLASSIC-253: ----------------------------------------- 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