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:
   
   
![Image](https://github.com/user-attachments/assets/2c6983a6-6ef3-48d1-88f4-2303d2160f04)
   
   
![Image](https://github.com/user-attachments/assets/e97d6977-a13e-4f91-a50b-7e756a3223e5)
   
   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

Reply via email to