When using a thread pool the processing starts to happen outside of the main web service thread so the MDC that is being used is completely unrelated to the original request. This means you can start logging data for requests that have completed running already.
This is how I went about making sure the correct MDC is maintained...
Java
package net.igorkromin;
import org.apache.log4j.MDC;
import java.util.Hashtable;
import java.util.concurrent.Callable;
public abstract class MdcCallable<T> implements Callable<T> {
private Hashtable contextCopy;
public MdcCallable() {
contextCopy = (Hashtable) MDC.getContext().clone();
}
public T call() throws Exception {
MDC.clear();
for (Object key : contextCopy.keySet()) {
MDC.put((String) key, contextCopy.get(key));
}
return process();
}
public abstract T process() throws Exception;
}
I created a small wrapper class that implements Callable. Since the Callable is going to be created within the context of the original web service thread the MDC that is available there is the correct one. So in the constructor I create a clone of that MDC context.
I also implement the call() method - this is called in the context of whatever Thread happens to be available from the pool so the MDC is cleared first to remove any previous requests' data, then I copy values from the cloned MDC context into the current MDC and call the abstract process() method.
To use this all I have to do is extend MdcCallable and implement the process() method instead of the usual approach of implementing Callable and the call() method.
It may not be very performant making clones of the MDC context every time so we ended up optimising this to look for specific key/values from the MDC but the approach is much the same as described above.
For this to work you will need the 1.2.17 version of log4j.
-i
