TL;DR: Are there any serious performance concerns to be aware of with
using something like...
doFilter(ServletRequest req, ServletResponse rsp, FilterChain c) {
final Map<String,String> ctx = ThreadContext.getContext();
try {
c.doFilter(req,rsp);
} finally {
ThreadContext.clearMap()
if ( ! ctz.isEmpty() ) { // typically empty
ThreadContext.putAll(ctx);
}
}
}
...
I'm dealing with a Servlet Container application where (I think) I'd like
to (somewhat defensively) stash & later restore the ThreadContext Map data
as the first & last actions of a ServletFilter that processes evey
request.
The idea being that I want to garuntee that the only ThreadContext MDC
values that exist in each (re-used) Thread when it initially starts
processing a request are the ones set by the ServletContainer itself (if
any) and that if any "leaked" MDC values still exist at the end of the
request, I want to ensure they are cleaned up -- not just as a defensive
measure against "bad code" that might call ThreadContext.put("foo",...)
w/o also calling ThreadContext.remove("foo"), but also because there are
some situations where modules/plugins of the application want to
explicitly set MDC values that exist for the duration of the requests
lifecycle - even once the module/plugin is "done" with the request (ie:
userId)
This _seems_ like something that would be very commonly done -- not
just in Servlet Containers but in any application where Threads get
re-used to process data/messages. I assumed if I went looking I'd find
lots of examples of this pattern in open source code, and/or utility
classes or helper plugins that bundle up this type of "Snapshot the
Context Map" logic in an AutoClosable ... but so far nothing.
Which leads me to wonder if this is because there is "enough" overhead (in
the ThreadContext internals) when doing this that it's not recommended
except as a last resort? (I poked around in the code a bit, but between
not being much of a concrrency expert, nor a log4j expert, nor a garbage
free expert - I got a little lost in being confident I understood what the
impacts were in the common/uncommon case)
So ultimatley I'm just hopeing someone can give me some advice on when/if
code like what I posted above would be a "bad idea" vs a "good idea" ?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
