> On Nov 8, 2021, at 3:04 PM, Chris Hostetter wrote:
>
>
> And if the ThreadContext is _not_ empty? ... is there anything about how
> it's implemented that would make the initial map copy (and later
> `putAll(...)` call) more "epensive" from a performance standpoint then an
> off the shelf
In a servlet environment, the overhead of MDC logging is minuscule compared to
the servlet itself. Allocating that in a filter is about the best you can do
here unless you don’t need it for all requests. In a reactive streams style web
app, though, that might be a little heavier due to copying c
: 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
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
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 ctx = ThreadContext.getContext();
try {
c.doFilter(req,rsp);
} finally {
ThreadContext.clearMap()
if (
: var ctx = (LoggerContext) LogManager.getContext(false);
: var current = ctx.getConfiguration();
: try {
: ctx.setConfiguration(myQuietConfiguration);
: otherCode();
: } finally {
: ctx.setConfiguration(current);
: }
:
: But it doesn't. Neither with reconfigure nor with setConfiguration.
