vy commented on issue #3399: URL: https://github.com/apache/logging-log4j2/issues/3399#issuecomment-2612403140
> I am stumbling upon (probably) the same problem and can reliably reproduce it. I could share stack traces if that helps, but sadly I cannot hand out a minimal example because we are using an internal library in our setup. > > Our setup reads from a zookeeper instance which log levels are configured, but the classes that do that contain loggers themselves. Until now this wasn't a problem. I suspect that due to the changes in locking between `LoggerRegistry` and `InternalLoggerRegistry` the thread that receives the answer from zookeeper is blocked trying to obtain its logger. @freelon, would you mind helping with the following questions, please? 1. What is the latest Log4j version that you do **not** observe this problem? 2. What is the latest Log4j version that you observe this problem? 3. Which JDK distribution and version do you use? 4. Do your application use virtual threads? If so, does upgrading to JDK 24-EA help with mitigating the problems you are having? 5. Would you mind sharing the stack trace, please? (If it contains information you don't want to disclose, you can email it to the `priv...@logging.apache.org` mailing list – see [the Logging Services support page](https://logging.apache.org/support.html) for details. This way, only Log4j maintainers will see it.) > Our setup reads from a zookeeper instance which log levels are configured, but the classes that do that contain loggers themselves. Until now this wasn't a problem. Would you mind elaborating on this, please? Maybe with a pseudo code example demonstrating the case? -- 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
