Personally, I wouldn’t bother. I have a standard practice of populating the
ThreadContextMap from HTTP headers in a ServletFilter and then clearing the
ThreadContext on the way out. See
https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/rest/RequestContextFilter.java
<https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/rest/RequestContextFilter.java>.
Because the ServletContainer uses thread pools to serve requests it is highly
unlikely it would stash anything in the ThreadContext before your Filter does.
But I suppose if the ThreadContext is always empty the cost of copying the map
won’t be too bad and the call to isEmpty should be cheap.
Ralph
> On Nov 8, 2021, at 12:27 PM, Chris Hostetter <hoss...@fucit.org> wrote:
>
>
>
> 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
>
>
