Hi there We want to use the SLF4J MDC feature in our asynchronous application (promise based). We therefore think that we have to propagate the MDC content between threads:
- when the job is submitted, save the MDC content - when the job is actually executed, restore the Mdc content BTW, we’re using Logback as the SLF4J implementation We have a couple of questions regarding our solution: - Is this the right way to use MDC in an asynchronous environment ? - If so, why slf4j doesn’t provide some kind of delegates that would take care of that propagation work for JDK’s ExecutorService ? That seems a valuable addition. We would be happy to contribute a set of ExecutorService delegate (in the helper package) to have that support out of the box. - When restoring the MDC, we save the previous MDC (can be null if there was none), why can’t we just set it back to `null` (MDC.setContextMap(previous), with previous that can be null) ? Right now, this is throwing NPE, and we have to call instead MDC.clear() (that seems to remove MDC entries, but nothing guarantee that we will go back in the exact previous state : MDC.getContextMap() returning null ). Is this behaviour intended ? Thanks Guillaume -- View this message in context: http://slf4j.42922.n3.nabble.com/MDC-support-in-asynchronous-applications-tp4026396.html Sent from the slf4j - user mailing list archive at Nabble.com. _______________________________________________ slf4j-user mailing list slf4j-user@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-user
