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
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
