[jboss-jira] [JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8

James Perkins (Jira) issues at jboss.org
Wed Dec 4 13:45:00 EST 2019


    [ https://issues.jboss.org/browse/LOGMGR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821096#comment-13821096 ] 

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)


More information about the jboss-jira mailing list