<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:D="DAV:" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:st="" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:Z="urn:schemas-microsoft-com:"><head><META content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta content="text/html; charset=utf-8" http-equiv=Content-Type>
<meta content="Microsoft Word 12 (filtered medium)" name=Generator>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
code
{mso-style-priority:99;
font-family:"Courier New";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head><BODY>
<DIV>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Hi,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p>
<pre><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I agree with Maarten, if the r.lock() call would be outside the try block than the original exception would be propagated. Having a look at the </span><code>RWDictionary </code><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>example in the javadocs of ReentrantReadWriteLock(http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html), they have the call to the lock() method outside of the try block.</span><o:p></o:p></pre>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:black'>Zoltan Szel<br>
</span><b><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
color:black'>Morgan Stanley | IDEAS Practice Areas<br>
</span></b><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
color:black'>Lechner Odon fasor 8 | Floor 07<br>
Budapest, 1095<br>
Phone: +36 1 881-3978<br>
<a href="mailto:Zoli.Szel@MorganStanley.com">Zoli.Szel@MorganStanley.com</a></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
logback-dev-bounces@qos.ch [mailto:logback-dev-bounces@qos.ch] <b>On Behalf Of </b>Maarten
Bosteels<br>
<b>Sent:</b> Tuesday, February 03, 2009 2:34 PM<br>
<b>To:</b> logback developers list<br>
<b>Subject:</b> Re: [logback-dev] IllegalMonitorStateException
inAppenderAttachableImpl.appendLoopOnAppenders()<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>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.<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>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 ??<o:p></o:p></p>
<pre> <strong><span style='font-family:"Courier New"'>public</span></strong> <strong><span style='font-family:"Courier New"'>int</span></strong> appendLoopOnAppenders(E e) {<br>
<br>
<o:p></o:p></pre><pre><a name=56></a> <strong><span style='font-family:"Courier New"'>int</span></strong> size = 0;<br>
<a name=58></a> r.lock();<br>
<br>
<o:p></o:p></pre><pre><a name=57></a> <strong><span style='font-family:"Courier New"'>try</span></strong> {<br>
<a name=59></a> <strong><span style='font-family:"Courier New"'>for</span></strong> (Appender<E> appender : appenderList) {<br>
<br>
<o:p></o:p></pre><pre><a name=60></a> appender.doAppend(e);<br>
<a name=61></a> size++;<br>
<br>
<o:p></o:p></pre><pre><a name=62></a> }<br>
<a name=63></a> } <strong><span style='font-family:"Courier New"'>finally</span></strong> {<br>
<br>
<o:p></o:p></pre><pre><a name=64></a> r.unlock();<br>
<a name=65></a> }<br>
<br>
<o:p></o:p></pre><pre><a name=66></a> <strong><span style='font-family:"Courier New"'>return</span></strong> size;<br>
<a name=67></a> }<br>
<br>
<o:p></o:p></pre><pre><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<o:p></o:p></pre>
<p class=MsoNormal><br>
<br>
In any case,<br>
> r.lock() will not throw an exception since the exception is absorbed<br>
> by the sync.acquireShared method.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal>On Tue, Feb 3, 2009 at 12:43 PM, Szel, Zoltan (IDEAS) <<a href="mailto:Zoli.Szel@morganstanley.com">Zoli.Szel@morganstanley.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal>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<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>Lechner Odon fasor 8 | Floor 07<br>
Budapest, 1095<br>
Phone: +36 1 881-3978<br>
Zoli.Szel@MorganStanley.com<o:p></o:p></p>
</div>
<div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>-----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><o:p></o:p></p>
</div>
</div>
<p class=MsoNormal>--------------------------------------------------------------------------<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal>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><o:p></o:p></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</DIV>
<DIV>
<HR>
</DIV>
<P CLASS="BulletedList" STYLE="MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; mso-list: none; tab-stops: .5in"><SPAN STYLE="FONT-SIZE: 8pt; COLOR: gray; mso-bidi-font-family: Arial"><FONT COLOR="gray" FACE="Arial" SIZE="1">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.</FONT></SPAN></P>
<DIV></DIV></BODY></HTML>