Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Wildfly logging pattern - shorter thread

126 views
Skip to first unread message

Christoffer A. Nilsen

unread,
Dec 4, 2024, 5:10:15 AM12/4/24
to WildFly
I'm configuring a Wildfly logging pattern, and with %t you get the callers thread. Ref.: https://github.com/wildfly/wildfly/blob/main/docs/src/main/asciidoc/_admin-guide/subsystem-configuration/Logging_Formatters.adoc#pattern-formatter
But this param takes a lot of space, examples:
2024-12-03T17:36:55,026 INFO  (ServerService Thread Pool -- 263)
2024-12-04T09:39:22,415 INFO  (default task-30)
2024-12-04T10:21:47,189 INFO  (management-handler-thread - 3)
2024-12-04T10:21:50,258 INFO (MSC service thread 1-6)

Does there exist a param I can use that just shows an unique thread id without all the text? Like: 
2024-12-03T17:36:55,026 INFO  (263)
2024-12-04T09:39:22,415 INFO  (30)
2024-12-04T10:21:47,189 INFO  (3)
2024-12-04T10:21:50,258 INFO (1-6)

Richard Opalka

unread,
Dec 4, 2024, 5:57:02 AM12/4/24
to Christoffer A. Nilsen, WildFly
Hello Christopher,

There is no such param for access log handler.

The proposal you have would mean that e.g.
(default task - 3)
and
(ServerService Thread Pool -- 3)
would map to the same value 3.

Richard

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/79bc134d-e37f-4527-956a-23da34bff689n%40googlegroups.com.

Christoffer A. Nilsen

unread,
Dec 5, 2024, 4:11:58 AM12/5/24
to WildFly
Thank you for your answer.

I does not need to be a thread ID as such, just an unique id of some sort.
Tbh, it would not be a huge issue if there was a small possibility of collisions ether. 

The way we do it today is that we manually add a small generated id as a part of the log message, 
but as soon as a part of the application that we do not control starts logging we lose this ID and need to follow the thread ID.
Typical example could be: a thread hangs, 2 minutes later we get an Exception from Wildfly saying it lost its connection to ActiveMQ.

Like (pseudo exception):
2024-12-04T09:39:22,415 INFO  (default task-30) [MyService][2a4123a]: We do something.
2024-12-04T09:49:22,415 INFO  (default task-30) [SendingService][2a4123a]: Start sending to ActiveMQ....
... (2 min later)
2024-12-04T 09:51:22,415  INFO   (default task-30)   LostConnectionSomethingException lost connection to ActiveMQ something...
     ...stacktrace...

The last exception won't have our id [2a4123a], so only way to follow this is by the thread id (default task-30).

The goal is to be able to follow the thread without having to log half a sentence worth of text on every log line.

Vilius Panevėžys

unread,
Dec 5, 2024, 9:33:44 AM12/5/24
to wil...@googlegroups.com, Christoffer A. Nilsen
On Thu, 5 Dec 2024 01:11:57 -0800 (PST)
"'Christoffer A. Nilsen' via WildFly" <wil...@googlegroups.com> wrote:

> The way we do it today is that we manually add a small generated id
> as a part of the log message,
> but as soon as a part of the application that we do not control
> starts logging we lose this ID and need to follow the thread ID.

Have you considered MDC [1]? The example doc link is SLF4J, but other
popular logging frameworks have something similar.


[1] https://www.slf4j.org/api/org/slf4j/MDC.html

James Perkins

unread,
Dec 5, 2024, 8:58:11 PM12/5/24
to WildFly
What is the goal of the id? As Vilius suggests, MDC or NDC might be an option.

Christoffer A. Nilsen

unread,
Dec 6, 2024, 9:00:42 AM12/6/24
to WildFly
Thanks to both of you for pointing out MDC, had never heard of it, and it looks to solve most of my problems!

James Perkins

unread,
Dec 6, 2024, 12:35:33 PM12/6/24
to WildFly
One thing to note is JUL does not have the concept of MDC or NDC. You'd need to use JBoss Logging, SLF4J, or the log4j2 API to use this type of thing.

Vilius Panevėžys

unread,
Dec 9, 2024, 3:17:10 AM12/9/24
to wil...@googlegroups.com
On Fri, 6 Dec 2024 09:35:33 -0800 (PST)
James Perkins <jper...@redhat.com> wrote:

> You'd need to use JBoss Logging, SLF4J, or the log4j2 API to use this
> type of thing.

Logback is also an option [1].


[1] https://logback.qos.ch/manual/mdc.html

James Perkins

unread,
Dec 9, 2024, 10:48:08 AM12/9/24
to WildFly
Logback is a log manager, not a logging facade. If you want to use Loback in WildFly, there are different steps you need to do to achieve that and server based logging will not be logged through Logback. Only your deployment can be logged through Logback.

Teixi

unread,
Dec 21, 2024, 11:58:59 AM12/21/24
to WildFly
Here you have 2 helpful guides, because the current WildFly documentation is confusing, outdated, or missing in regards to switching the default jboss-logging

1 Set the system property org.jboss.logging.provider 
From WildFly repo (but not in documentation) https://github.com/jboss-logging/jboss-logging 
'"You can define the specific log manager you want to use by specifying the org.jboss.logging.provider system property. 
The following is the mapping of the property value to the log manager.
Property Value.     Log Manager
jboss                     JBoss Log Manager (default)
jdk                          Java Util Logging
log4j2                   Log4j 2
log4j                     log4j
slf4j                     SLF4J and Logback"

For example adding the system property in the JAVA_OPTS before launching WildFly:
export JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.logging.provider=slf4j"

Then you will need to add the dependencies for either
slf4j-api
slf4j-simple
   or
slf4j-api
logback-core
logback-classic

James Perkins

unread,
Jan 2, 2025, 6:30:14 PMJan 2
to WildFly
FWIW WildFly is not really meant to be used with another log manager other than the jboss-logmanager. Deployments can include their own log manager if desired. However, the server itself should use the jboss-logmanager.

Christoffer A. Nilsen

unread,
Jan 3, 2025, 9:34:03 AMJan 3
to WildFly
Thanks all, I'm using the provided jboss-logging maven dependency, now using MDC to set an uniquely generated id everywhere there is an entry point, such as:

@Startup
public class Boot {
    @PostConstruct
    public void init() {
       MDC.put("context.id", UUID.randomUUID().toString().substring(0, 5));
       ...
    }
}

@Schedule(...)
public void doSomething() {
   MDC.put("context.id", UUID.randomUUID().toString().substring(0, 5));
   ...
}

@Override
public void onMessage(final Message message) {
   MDC.put("context.id", UUID.randomUUID().toString().substring(0, 5));
   ...
}

and have changed my Pattern Formatter to:
%d{yyyy-MM-dd}T%d{HH:mm:ss,SSS} %-5p [%C{1}][%X{context.id}]: %s%e%n
It looks like it solves all of my problems.

Teixi

unread,
Jan 3, 2025, 2:31:33 PMJan 3
to WildFly
AFAIK it works nicely for both WildFly server & RESTEasy war deployment logging.

Just by setting:

1. System Property:
 -Dorg.jboss.logging.provider=slf4j

2. Dependencies:
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.16</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>2.0.16</version>
    <scope>test</scope>
</dependency>


I am doing anything outside current implementation?

James Perkins

unread,
Jan 3, 2025, 2:42:12 PMJan 3
to WildFly
That should work, but you're creating an extra call when logging anything from the server components. What I mean by that is, sfl4j will likely be logging to the the org.jboss.logging:slf4j-jboss-logmanager which then writes to the jboss-logmanager. I assume too, though I've not tested, that you'd need to exclude the logging subsystem from your deployment or exclude the org.slf4j module dependency from your deployment.

All that said, I don't really see what the advantage would be there. Using the logging subsystem, you can use the slf4j-api as a provider is provided. You also have more control of changing the logging configuration at runtime with the logging subsystem.

Teixi

unread,
Jan 3, 2025, 2:44:00 PMJan 3
to WildFly
Right now can't recall the exact reason for the this war deployment to have it to have WildFly to use slf4j-simple with MDC custom additional params, ... perhaps because of using JSON formatter, specifics of war deployment, or else... ?

Nevertheless congrats C! that you could add your own MDC.put() only via default JBoss Log Manager, without configuring neither log4j nor slf4j, cool!

Teixi

unread,
Jan 3, 2025, 3:12:37 PMJan 3
to WildFly
Funny thing is that this case is using logging-profile, as well not excluding org.jboss.as.logging in the standalone xml config, with then same Logging-Profile in the war deployment manifest as well.

I can't recall what let me to this configuration, but somehow it was a combination of using: JSON formatter + MDC + console-access-log + RESTEasy + specific war deployment dependencies logging reconfig specifics... or else....

Because of the specific dependencies maybe I can't easily provide a simple reproducible example, yet possibly easily provide xml config, manifest, plust server startup & auto-deployment startup logs...  

Anyway cool to read that the OP could simply use MDC.put additional params with default config ;)

James Perkins

unread,
Jan 3, 2025, 3:55:50 PMJan 3
to WildFly
Indeed MDC should work. You should be able to use MDC from Log4j 2, slf4j or JBoss Logging. It should also just show up in the JSON format. There is https://issues.redhat.com/browse/LOGMGR-284 for MDC to be written as a flat map to the JSON output which is something that does seem nice to have an option for. I've just not yet implemented it.

The console-access-log is a bit different. It does use JBoss Logging as well, but isn't configured through the logging subsystem in some cases. RESTEasy itself uses JBoss Logging as well.

Anyway, feel free to ping me with questions. I happen to the the logging and RESTEasy project lead :)

Teixi

unread,
Jan 3, 2025, 4:38:59 PMJan 3
to WildFly
hehe ;) I became aware once learned of the 'supported log managers' reading the repo readme: https://github.com/jboss-logging/jboss-logging?tab=readme-ov-file#supported-log-managers

At first your 'FWIW' confused me, but then your further clarifications much appreciated & helpful!

Will try to find some time to sent more feedback from my logging experiences ASAP in a new thread ;)

Thanks J!

Christoffer A. Nilsen

unread,
Jan 24, 2025, 4:17:58 AMJan 24
to WildFly
I have discovered that after swapping to using Logging-Profile's, some log lines are still logged not using the correct Logging-Profile.

Examples lines (not ordered or necessarily relevant to each other):
2025-01-23T19:58:55,005 WARN  (EJB default - 2) IJ000621: Destroying connection that could not be validated.....
2025-01-23T14:06:00,821 WARN  (Thread-2553 (ActiveMQ-client-global-threads)) SQL Error: 1, SQLState: 23000
2025-01-23T14:06:00,821 ERROR (Thread-2553 (ActiveMQ-client-global-threads)) ORA-00001: unique constraint (...) violated...
2025-01-23T14:06:00,772 ERROR (Thread-2571 (ActiveMQ-client-global-threads)) IJ031070: Transaction cannot proceed: STATUS_MARKED_ROLLBACK

These lines, usually some sort of error/warn/stack trace are still logged with the Default/Root logger, instead of my logging profile.
I could see the error about destroying a connection being only tied to Wildfly and not a specific artifact, therefore logging with root configuration, but unique constraint log is very much the cause of an artifact, and I would think it should use the configurated logger profile?
Is this the expected behavior? Anyway around this?

James Perkins

unread,
Jan 24, 2025, 1:18:21 PMJan 24
to WildFly
Hello Christopher,
Yes this is expected behavior. Logging from server modules will use the logging configuration from the root logging subsystem. There is a long standing issue, https://issues.redhat.com/browse/WFCORE-4807, to allow these kinds of log messages to be logged with the logging profiles log context. However, it's something that I need to look at again.

Reply all
Reply to author
Forward
0 new messages