[logback-dev] IllegalMonitorStateException inAppenderAttachableImpl.appendLoopOnAppenders()

Tue Feb 3 14:34:27 CET 2009

Hello,

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

> Looking at this exception and related code in AppenderAttachableImpl,
> moving the r.lock(); statement outside of the try block will not
> change anything because I believe that r.lock() does not throw
> exceptions. However, looking at ReentrantReadWriteLock.ReadLock class'
> lock() method, one is directed to the ReentrantReadWriteLock.Sync
> class and its acquireShared() method. If this method fails to acquire
> the lock due to a RuntimeException, then the subsequent r.unlock()
> call will fail with an IllegalMonitorStateException.

but if I understand correctly there will be no subsequent call to r.unlock
in this case ??

  *public* *int* appendLoopOnAppenders(E e) {
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#56>
   *int* size = 0;
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#58>
   r.lock();
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#57>
   *try* {
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#59>
     *for* (Appender<E> appender : appenderList) {
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#60>
       appender.doAppend(e);
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#61>
       size++;
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#62>
     }
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#63>
   } *finally* {
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#64>
     r.unlock();
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#65>
   }
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#66>
   *return* size;
 <http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#67>
 }

Noiw, when r.lock() throws a RuntimeException, this one will be
propagated to the caller, and we don't reach r.unlock(), right ?

Maarten

 In any case,
> r.lock() will not throw an exception since the exception is absorbed
> by the sync.acquireShared method.

On Tue, Feb 3, 2009 at 12:43 PM, Szel, Zoltan (IDEAS) <
Zoli.Szel at morganstanley.com> wrote:

> Hi,
>
> Unfortunately not, we cannot reproduce it but we have the strong feeling
> this is about out of memory as you mentioned.
>
> Regards,
> Zoltan Szel
> Morgan Stanley | IDEAS Practice Areas
> Lechner Odon fasor 8 | Floor 07
> Budapest, 1095
> Phone: +36 1 881-3978
> Zoli.Szel at MorganStanley.com
>
> -----Original Message-----
> From: Ceki Gulcu [mailto:ceki at qos.ch]
> Sent: Monday, February 02, 2009 11:17 PM
> To: logback developers list
> Subject: Re: [logback-dev] IllegalMonitorStateException in
> AppenderAttachableImpl.appendLoopOnAppenders()
>
>
> Any luck reproducing this issue?
>
> Ceki Gulcu wrote:
> > Hello Zoltan,
> >
> > Looking at this exception and related code in AppenderAttachableImpl,
> > moving the r.lock(); statement outside of the try block will not
> > change anything because I believe that r.lock() does not throw
> > exceptions. However, looking at ReentrantReadWriteLock.ReadLock class'
> > lock() method, one is directed to the ReentrantReadWriteLock.Sync
> > class and its acquireShared() method. If this method fails to acquire
> > the lock due to a RuntimeException, then the subsequent r.unlock()
> > call will fail with an IllegalMonitorStateException. In any case,
> > r.lock() will not throw an exception since the exception is absorbed
> > by the sync.acquireShared method.
> >
> > It would be quite helpful if you were able to reproduce the problem.
> >
> > We could place the r.unlock() invocation within a try/catch block
> > (absorbing the IllegalMonitorStateException you got). However, this is
> > may only obfuscate the real cause of the problem, that is an
> > OutOfMemoryException or such. We could also imagine that there is a
> > bug in ReentrantReadWriteLock. Given its complexity, it's not such an
> > outlandish hypothesis.
> >
> > Otherwise, the only remaining possibility is a bug in logback. But we
> > all know that is impossible.
> >
> > More seriously, I think this bug will be hard to nail down.
> >
> > Szel, Zoltan (IDEAS) wrote:
> >> Hi,
> >>
> >>
> >>
> >> We have hit the exception mentioned in the subject in one of our
> >> applications. We are using JDK 6 and Logback 0.9.14.  Here is the
> >> stacktrace:
> >>
> >> Caused by: java.lang.IllegalMonitorStateException
> >>  at
> >>
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:363)
> >>
> >>  at
> >>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1253)
> >>
> >>  at
> >>
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:745)
> >>
> >>  at
> >>
> ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:64)
> >>
> >>  at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
> >>  at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
> >>  at
> >>
> ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439)
> >>  at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:411)
> >>  at ch.qos.logback.classic.Logger.debug(Logger.java:504)
> >>
> >>
> >>
> >> I have checked the code and it seems to me this can only happen if the
> >> readLock.lock() method throws an exception:
> >>
> >> *public* *int* appendLoopOnAppenders(E e) {
> >>
> >> 56
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#56
> >
> >> *int* size = 0;
> >>
> >> 57
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#57
> >
> >> *try* {
> >>
> >> 58
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#58
> >
> >> r.lock();
> >>
> >> 59
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#59
> >
> >> *for* (Appender<E> appender : appenderList) {
> >>
> >> 60
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#60
> >
> >> appender.doAppend(e);
> >>
> >> 61
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#61
> >
> >> size++;
> >>
> >> 62
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#62
> >
> >> }
> >>
> >> 63
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#63
> >
> >> } *finally* {
> >>
> >> 64
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#64
> >
> >> r.unlock();
> >>
> >> 65
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#65
> >
> >> }
> >>
> >> 66
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#66
> >
> >> *return* size;
> >>
> >> 67
> >> <
> http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#67
> >
> >> }
> >>
> >>
> >>
> >> if r.lock() in line 58 throws an exception for some reason than in the
> >> finally block the unlock will throw also an exception which will hide
> >> the original one. I cannot see any other reason why the unlock would
> >> throw this exception in this scenario. I am not yet able to reproduce
> >> it, but I thought this exception worth a mail. The only suggestion I
> >> have for now is to move the r.lock() call out of the try block,
> >> because if that is the bad guy, than we would have the original
> >> exception propagated.
> >>
> >>
> >>
> >> If I have more information on this issue I will update this thread.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Zoltan Szel
> >> *Morgan Stanley | IDEAS PRACTICE AREAS
> >> *Lechner Odon fasor 8 | Floor 07
> >> Budapest, 1095
> >> Phone: +36 1 881-3978
> >> Zoli.Szel at MorganStanley.com <mailto:Zoli.Szel at MorganStanley.com>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> NOTICE: If received in error, please destroy and notify sender. Sender
> >> does not intend to waive confidentiality or privilege. Use of this
> >> email is prohibited when received in error.
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> logback-dev mailing list
> >> logback-dev at qos.ch
> >> http://qos.ch/mailman/listinfo/logback-dev
> >
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> --------------------------------------------------------------------------
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-dev/attachments/20090203/99fbd138/attachment-0001.htm>