[slf4j-dev] [Bug 176] Initialization (getILoggerFactory) is not thread safe

[bugzilla-daemon at qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=176

Simon Arlott <bugzilla.slf4j.simon at arlott.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla.slf4j.simon at arlott
                   |                            |.org

--- Comment #20 from Simon Arlott <bugzilla.slf4j.simon at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20130609/8cff716b/attachment.html>