http://bugzilla.slf4j.org/show_bug.cgi?id=176 Simon Arlott <bugzilla.slf4j.simon@arlott.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla.slf4j.simon@arlott | |.org --- Comment #20 from Simon Arlott <bugzilla.slf4j.simon@arlott.org> --- (In reply to comment #19)
What is the status of this? If you want an alternative thread-safe initialisation that is not bespoke, we have a class that encapsulates lazy but thread-safe initialisation:
The problem is that the logger initialisation process may try to log something via SLF4J. There are three scenarios for calling getILoggerFactory() during initialisation: 1. This is the thread that is doing the initialisation. 2. This is another thread that just wants to create a Logger. 3. This is another thread that the initialisation thread is blocked on (e.g. the logger factory initialises itself in another thread which then tries to log something). For scenario 1, we return a TEMP_FACTORY and everything is ok. For scenario 2, we should wait indefinitely for initialisation to complete or fail. For scenario 3, we need to return a TEMP_FACTORY or a deadlock will occur. One way to distinguish between 2 and 3 is to wait N seconds for initialisation to complete before giving up, but there is no good value for N (perhaps you're logging over NFS and the network is temporarily overloaded). Ideally all locking performed during logger factory initialisation would be performed with something like Guava's CycleDetectingLockFactory so that we could detect deadlocks, but that would impose a requirement on all of the logging frameworks (and not just the binding code). To resolve this bug, either: 1. Allow scenario 3 to cause a deadlock so that scenario 2 works. 2. Implement a long enough timeout before failing, to cover most environments. This could log warnings to System.err after a short period of time. 3. Return a proxy factory that uses a caching logger until initialisation is complete. All loggers obtained during concurrent initialisation will be less efficient. On servers with many CPUs this could potentially be a lot of static class loggers. 4. Find a VM independent mechanism for detecting a deadlock that doesn't require modifying code outside of the binding. Note that scenario 1 is unchanged. It must return a NOP factory (or the proxy factory if option 3 is used). MarkerFactory and MDC have a similar problem. MarkerFactory will throw a NullPointerException and MDC will throw an IllegalStateException. -- You are receiving this mail because: You are the assignee for the bug.