Wildfly JSON Formatter with MDC

[Christoffer A. Nilsen]

I'm trying to use Wildfly's Socket Handler with a JSON Formatter to do centralized logging to Logstash. It works, but I'm having issues getting my MDC key/values.

The default JSON Formatter seems to add a mdc object to the JSON, as can be seen below:

{
   "timestamp": "2025-06-24T17:11:12.728+02:00",
   "sequence": 91,
   "loggerClassName": "org.jboss.logging.Logger",
   "loggerName": "com.something.api.filter.ResponseLoggingFilter",
   "level": "INFO",
   "message": "Response: [400]",
   "threadName": "default task-3",
   "threadId": 162,
   "mdc": {},
   "ndc": "",
   "hostName": "xxxwf10",
   "processName": "jboss-modules.jar",
   "processId": 32742
}

But the mdc object is empty.

My pattern-formatter, that I use for logging to file, accesses the MDC with %X{context.id}, and I can verify that my lines in the log file contains the MDC values as expected.

Do I need to do something to enable getting my MDC key/values to the JSON Formatter?

[James Perkins]

No, MDC should be showing up by default. What logging framework are you using and what version of WildFly?

[Christoffer A. Nilsen]

Wildly 31.0.1.Final with org.jboss.logging:jboss-logging:3.5.3.Final

I have two log handlers, one Periodic Handler that logs to file with the Pattern Formatter:  %d{yyyy-MM-dd}T%d{HH:mm:ss,SSS} %-5p [%C{1}][%X{context.id}] %s%e%n

Where I can verify that I do get my MDC value: context.id. Random example taken from my log file: 

2025-06-27T01:02:30,098 INFO  [ResponseLoggingFilter][bd8c546e]: Response: [ip:XX.XXX.XXX.XXX] [response:400] [duration:102]

Here I set the MDC key/value in my ContainerRequestFilter.class for incoming jaxrs requests:

MDC.put("context.id", UUID.randomUUID().toString().substring(0, 8));

The other one is the SocketHandler where I try to use the JSON Formatter, and I'm not able to get the MDC values.

[James Perkins]

Is your REST request async?

[Christoffer A. Nilsen]

I have no idea what is happening, but on further testing it seems to be suddenly working.

Seems to be working after a Wildfly restart. No code changes or any changes to my JSON Formatter.

Does the MDC persist across deployments? 

It seems like I have to restart the whole Wildfly to be able to remove entries in the MDC.

I added a MDC.put("test", "hello world")  directly in my resource endpoint, saw that it appeared in my JSON, removed it and redeployed, still got the {"test": "hello world"} in my JSON.

Added MDC.clear() to my ContainerResponseFilter, but still got {"test": "hello world"} in my JSON. After restarting Wildfly it disappeared.

I thought the MDC was thread-safe, how can it reuse MDC values from a previously deployed artifact if it is thread-safe?

[James Perkins]

That sounds like a bug. It uses a ThreadLocal so what is likely happening is something is not invoking MDC.clear() on the correct thread. Are you invoking MDC.put() ad MDC.clear() from the same thread?

[Christoffer A. Nilsen]

When looking at the logs from before this weekend it seems the same thread.ids have been used. 

I have not configured Wildfly to do anything different when it comes to the threads.

So my guess is that Wildfly have just decided  to reuse the threads for multiple API requests. Maybe this is expected behaviour and/or random.

Still I'm 99% sure I removed the MDC.put("test", "hello world") and redeployed the artifact(multiple times) and the MDC value still persisted, is this expected behaviour?

I will make sure my implementation of ContainerResponseFilter does a MDC.clear() and that should solve this issue I'm guessing.

Also have not had any issues with the MDC values not showing up in my JSON.

Going to implement this for tons of applications, will report if we see the same behaviour.

[Christoffer A. Nilsen]

Quick note: What I meant by the same threads have been used, that was not necessarily for MDC.clear(), but the reason for why "test"="hello world" showed up even if it was removed from the code.

[James Perkins]

Yeah, MDC.clear() or MDC.remove() should be used after log messages have been done. One thing we should likely look in WildFly is to ensure MDC.clear() is invoked after a threads execution. This would only work for cases when a managed thread is used.