Hi Friends, I've been thinking about ways that we can solve LOG4J2-2965 which is a deadlock between JUL init and log4j init, both of which use synchronization. The crux of the issue is that JUL LogManager uses a synchronized block to initialize, which requests log4j-core initialization and log4j-core attempts to initialize the JUL LogManager if Disruptor is used. If One thread attempts to initialize JUL directly while another begins to initialize log4j via a non-jul path, we may deadlock. I have an example stack trace in the ticket.
This problem is specific to JUL due to the synchronization incurred while initializing our LogManager via java.util.logging.LogManager, so we could update our JUL implementation to lazily connect jul logger instances to the log4j framework. Instead of reaching out to the loggercontext when JUL loggers are requested, we can initialize the delegate log4j components upon the first interaction rather than when the logger is requested, decoupling JUL LogManager initialization from log4j init so it behaves like other bindings. We would need to be careful to track the original caller data to avoid associating JUL loggers with incorrect log4j contexts. What do you think? Any alternative ideas or suggestions? Thanks, Carter
