[logback-dev] IllegalMonitorStateException inAppenderAttachableImpl.appendLoopOnAppenders()

Ceki Gulcu ceki at qos.ch
Tue Feb 3 17:54:13 CET 2009

Hi Maarteen,

Maarten Bosteels wrote:
> Hello,
> I think moving r.lock(); outside of the try block WILL help, because the 
> original exception will no longer be hidden.

Moving r.lock() outside the try block MAY help because the finally
block which throws a related but distinct exception will no longer be
invoked. The second exception effectively hides the first
exception. However, this is true if r.lock() throws an exception
*visible* in logback code. I tend to think, for reasons explained in
my previous post, that somewhere within r.lock() call there is a
RuntimeException thrown but which is absorbed somewhere within the
r.lock() invocation. So, there is a good chance (but less than 100%)
that displacing the r.lock() call to outside the try block will *not*
reveal anything new.

Having said that, if for one reason or another, the r.lock() call
throws an exception, which it certainly does, even if it is not
visible, there is arguably no point in calling r.unlock(). Calling
r.lock() outside the try block MAY reveal the original exception
without having a downside. On the other hand, if calling r.unlock has
a positive side-effect even if r.lock() fails, then moving r.lock()
outside the try block may not be such a good idea after all.

To summarize, although not guaranteed, there is a good chance that
moving the r.lock() call outside the try block will reveal new
information. However, this change may be problematic in certain cases,
which at this time we can only imagine but not pinpoint to. In
Rumsfeld-speak, moving r.lock has a known but uncertain positive
effect and uncertain and unknown negative effects.

Alternatively, we could invoke r.unlock in a safe manner, that is
within a try/catch block (embedded within finally). This would not
obfuscate the first exception and would ensure that r.unlock is always

I am not sure splitting hairs as demonstrated above gets us any closer
to a solution. Zoltan, do you need any specific help from my side?

Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.

More information about the logback-dev mailing list