Re: downsides/overhead of stashing & restoring (probably empty) ThreadContextMap ?

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 <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
> 
>