tristantarrant commented on issue #3399: URL: https://github.com/apache/logging-log4j2/issues/3399#issuecomment-2621037422
> [@tristantarrant](https://github.com/tristantarrant), [@nilsson-petter](https://github.com/nilsson-petter), are you sure you're using a local build compiled from the [#3418](https://github.com/apache/logging-log4j2/pull/3418), which is a PR and not included with any `2.x-SNAPSHOT` published by Log4j yet. The steps to build it are: Yes, I'm sure:   I modified the Infinispan pom.xml to use that SNAPSHOT version and ran its core testsuite using Maven in offline mode and with debug options to ensure that the Surefire classpath pointed to the correct jar. I also used OpenJDK 17 to avoid any potential vthread interference. A thread dump from a fresh run this morning https://gist.github.com/tristantarrant/93b0a80974a14cbc01d6d3ed71f540ba The above includes read locks: `org.apache.logging.log4j.core.util.internal.InternalLoggerRegistry.computeIfAbsent(InternalLoggerRegistry.java:145` and write locks: `org.apache.logging.log4j.core.util.internal.InternalLoggerRegistry.computeIfAbsent(InternalLoggerRegistry.java:177)` which are obviously lines from the patched code. There are 84 threads waiting for the same lock (`0x00000000c0334a58`), 16 of which on the read lock and 68 on the write lock. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org