[slf4j-user] MDC support in asynchronous applications

[Ceki Gulcu]

Hi Guillaume,

I am guessing that any support for helping propagate MDC to various 
threads is probably going to be added to logback instead of SLF4J. Can 
you please create a Jira issue in the logback project for this problem 
so that it does not fall through the cracks?

Thank you,

--
Ceki

On 5/4/2016 14:21, sauthieg wrote:
> 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 at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>