[
https://issues.jboss.org/browse/LOGMGR-263?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGMGR-263:
--------------------------------------
Okay that makes more sense :) This would be due to the {{LogContextSelector}} used in
WildFly. Every time a logger is created the call stack is examined to determine which log
context to use. This is for when logging profiles are used or a deployment includes a
logging configuration file.
I would actually recommend the opposite and advocate static loggers. If you're not
using logging profiles or including a logging configuration in your deployment then there
should be no issues. If you are using one of the two the only possible issue would be
what's described in WFCORE-3376. I'm actually working on a solution for this right
now.
The main reason to use a static logger is performance. If non-static loggers are used they
will be GC'd and re-created as needed. This could definitely cause a performance
impact.
Logger Lookup is much slower as with JDK 8
------------------------------------------
Key: LOGMGR-263
URL:
https://issues.jboss.org/browse/LOGMGR-263
Project: JBoss Log Manager
Issue Type: Bug
Environment: WildFly 17, OpenJDK 11
Reporter: Andreas Liebscher
Priority: Major
Attachments: grafik1570016303722 (1).png, grafik1570016303722.png,
grafik1570016791285.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:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)