]
James Perkins commented on LOGMGR-263:
--------------------------------------
Thank you for the analysis [~papegaaij]. That is an interesting workaround for sure.
I'll have to look at some workarounds for this or possibly a way to disable the class
walker and use the old approach.
The main reason for requiring this is looking for class loaders on the call stack that
have a specific log context configuration. A class loader could be registered for a
deployment if there is a {{logging-profile}} being used or the deployment contains a
logging configuration. One approach might be in WildFly itself to not walk the stack if no
logging profiles are defined or no deployments contain logging configuration files.
Logger Lookup is much slower as with JDK 8
------------------------------------------
Key: LOGMGR-263
URL:
https://issues.redhat.com/browse/LOGMGR-263
Project: JBoss Log Manager
Issue Type: Bug
Environment: WildFly 17, OpenJDK 11
Reporter: Andreas Liebscher
Priority: Major
Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt,
grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png,
responsetimes.png
During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK
11 we had a serious performance issue. We identified the usage of the logging framework
SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason
when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to
some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8
got a performance improvement with the added `static` keyword.
Please check the VisualVM output as prove of JDKSpecific got slower: