[logback-user] Problems with MDC's inheritance

[Lóránt Pintér]

Hi,

AFAIK, Log4J's MDC had no inheritance between threads -- this is a new
feature introduced in Logback. However, when you are using thread pools,
this new feature can cause a lot of trouble, especially when moving to
Logback from a different logging system.

Consider the following situation: you have a web application where you use
the MDC to keep track of which user is logged in. You do certain things on
the request processing thread. There are other certain things that you want
to execute "in the background". You want to print the originating user's
name in the logs for both "foreground" and "background" tasks.

In such a case the Runnable's you place on the thread pool's queue need to
take care of retaining the MDC from the originating thread. If you do this,
and do this in every instance, no problem. However, it happens that you
forget to do this. In such a case, with Log4J's non-inherited MDC, you would
get no user name printed in the logs for background tasks, because your
thread pool threads would not have anything in the MDC. That's not a good
situation, but at least you can spot that there's something missing.

OTOH, if you forget to retain the MDC manually with Logback, instead of no
data you get false data in the logs. This is because thread pool threads are
going to be created with random parent threads. These thread pool threads
will then inherit the MDC from these threads, and *keep* the MDC. So future
Runnables passed to these threads will print their starting thread's
username.

False data is worse than no data, so it would be nice to avoid this. Is
there a way to make Logback's MDC inheritance configuratble? Like, in
logback.xml you could set if you wanted to use InheritableThreadLocals or
not. If that doesn't work, it might even be better to have no inheritance at
all.

What do you think?

Regards,
Lorant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-user/attachments/20110530/7daba2f9/attachment.html>