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