<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><title></title><style type="text/css">body{padding:1ex;margin:0px;font-family:sans-serif;font-size:small;}a[href]{color:-moz-hyperlinktext !important;text-decoration:-moz-anchor-decoration;}blockquote{margin:0;border-left:2px solid #144fae;padding-left:1em;}blockquote blockquote{border-color:#006312;}blockquote blockquote blockquote{border-color:#540000;}</style></head><body><div style="font-family: Arial; font-size: medium;" dir="ltr"><div>Hi all. </div>
<div> </div>
<div>Sorry Martin I missed reading your last email. I am not confident that I will get a small reproducible test case in a reasonable time frame. Reproducing it with the application is easy and I will see what I can do about getting the source available.</div>
<div> </div>
<div>One interesting thing I can tell you is that if I remove the LinkedBlockingDeque from the mailbox of the Initiator the system still deadlocks. The cluster has a TCP mesh topology so any node can deliver messages to any other node. One of the connections goes dead and neither side detects that there is a problem. I add some assertions to the network selection thread to check that all the connections in the cluster are still healthy and assert that they have the correct interests set.</div>
<div> </div>
<div>Here are the things it checks for  to make sure each connection is working:</div>
<div>>                             for (ForeignHost.Port port : foreignHostPorts) {<br>
>                             assert(port.m_selectionKey.isValid());<br>
>                             assert(port.m_selectionKey.selector() == m_selector);<br>
>                             assert(port.m_channel.isOpen());<br>
>                             assert(((SocketChannel)port.m_channel).isConnected());<br>
>                             assert(((SocketChannel)port.m_channel).socket().isInputShutdown() == false);<br>
>                             assert(((SocketChannel)port.m_channel).socket().isOutputShutdown() == false);<br>
>                             assert(((SocketChannel)port.m_channel).isOpen());<br>
>                             assert(((SocketChannel)port.m_channel).isRegistered());<br>
>                             assert(((SocketChannel)port.m_channel).keyFor(m_selector) != null);<br>
>                             assert(((SocketChannel)port.m_channel).keyFor(m_selector) == port.m_selectionKey);<br>
>                             if (m_selector.selectedKeys().contains(port.m_selectionKey)) {<br>
>                                 assert((port.m_selectionKey.interestOps() & SelectionKey.OP_READ) != 0);<br>
>                                 assert((port.m_selectionKey.interestOps() & SelectionKey.OP_WRITE) != 0);<br>
>                             } else {<br>
>                                 if (port.isRunning()) {<br>
>                                     assert(port.m_selectionKey.interestOps() == 0);<br>
>                                 } else {<br>
>                                     port.m_selectionKey.interestOps(SelectionKey.OP_READ | SelectionKey.OP_WRITE);<br>
>                                     assert((port.interestOps() & SelectionKey.OP_READ) != 0);<br>
>                                     assert((port.interestOps() & SelectionKey.OP_WRITE) != 0);<br>
>                                 }<br>
>                             }<br>
>                             assert(m_selector.isOpen());<br>
>                             assert(m_selector.keys().contains(port.m_selectionKey));<br>
OP_READ | OP_WRITE is set as the interest ops every time through, and there is no other code that changes the interest ops during execution. The application will run for a while and then one of the connections will stop being selected on both sides. If I step in with the debugger on either side everything looks correct. The keys have the correct interest ops and the selectors have the keys in their key set.</div>
<div> </div>
<div>What I suspect is happening is that a bug on one node stops the socket from being selected (for both read and write), and eventually the socket fills up and can't be written to by the other side.</div>
<div> </div>
<div>If I can get my VPN access together tomorrow I will run with -XX:+UseMembar and also try running on some 8-core AMD machines. Otherwise I will have to get to it Wednesday.</div>
<div> </div>
<div>Thanks,</div>
<div> </div>
<div>Ariel Weisberg</div>
<div> </div>
<div> </div>
<div>On Tue, 14 Jul 2009 05:00 +1000, "David Holmes" <davidcholmes@aapt.net.au> wrote:</div>
<blockquote type="cite" class="QuoteMessage">
<div><span class="047275522-13072009"><font face="Courier New" color="#0000ff" size="2">Martin,</font></span></div>
<div> </div>
<div><span class="047275522-13072009"><font face="Courier New" color="#0000ff" size="2">I don't think this is due to LBQ/D. This is looking similar to a couple  of other ReentrantLock/AQS "lost wakeup" hangs that I've got on the radar. We  have a reprodeucible test case for one issue but it only fails on one kind of  system - x4450. I'm on vacation most of this week but will try and get back to  this next week.</font></span></div>
<div> </div>
<div><span class="047275522-13072009"><font face="Courier New" color="#0000ff" size="2">Ariel: one thing to try please see if -XX:+UseMembar fixes the  problem.</font></span></div>
<div> </div>
<div><span class="047275522-13072009"><font face="Courier New" color="#0000ff" size="2">Thanks,</font></span></div>
<div><span class="047275522-13072009"><font face="Courier New" color="#0000ff" size="2">David Holmes</font></span></div>
<blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
<div align="left" dir="ltr" class="OutlookMessageHeader"><font face="Tahoma" size="2">-----Original Message-----<br>
<b>From:</b> Martin Buchholz    [mailto:martinrb@google.com]<br>
<b>Sent:</b> Tuesday, 14 July 2009 8:38    AM<br>
<b>To:</b> Ariel Weisberg<br>
<b>Cc:</b> davidcholmes@aapt.net.au;    core-libs-dev; concurrency-interest@cs.oswego.edu<br>
<b>Subject:</b> Re:    [concurrency-interest] LinkedBlockingDeque deadlock?<br>
<br>
</font></div>
I did    some stack trace eyeballing and did a mini-audit of the    <br>
LinkedBlockingDeque code, with a view to finding possible bugs,<br>
and    came up empty.  Maybe it's a deep bug in hotspot?<br>
<br>
Ariel, it would    be good if you could get a reproducible test case soonish,<br>
while someone on    the planet has the motivation and familiarity to fix it.<br>
In another month I    may disavow all knowledge of j.u.c.*Blocking*<br>
<br>
Martin<br>
<br>
<br>
<div class="gmail_quote">On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg <span dir="ltr"><<a href="mailto:ariel@weisberg.ws">ariel@weisberg.ws</a>></span> wrote:<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Hi,<br>
<div class="im"><br>
> The poll()ing thread is blocked waiting for the      internal lock, but<br>
> there's<br>
> no indication of any thread      owning that lock. You're using an OpenJDK 6<br>
> build ... can you try      JDK7 ?<br>
 </div>
I got a chance to do that today. I downloaded JDK 7      from<br>
<a target="_blank" href="http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin">http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin</a><br>
and      was able to reproduce the problem. I have attached the stack trace<br>
from      running the 1.7 version. It is the same situation as before except<br>
there      are 9 execution sites running on each host. There are no threads<br>
that are      missing or that have been restarted. Foo Network thread<br>
(selector thread)      and Network Thread - 0 are waiting on<br>
0x00002aaab43d3b28. I also ran with      JDK 7 and 6 and LinkedBlockingQueue<br>
and was not able to recreate the      problem using that structure.<br>
<div class="im"><br>
> I don't recall anything similar to this, but I don't      know what version<br>
> that<br>
> OpenJDK6 build relates      to.<br>
 </div>
The cluster is running on CentOS 5.3.<br>
>[aweisberg@3f      ~]$ rpm -qi java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5<br>
>Name             : java-1.6.0-openjdk                Relocations: (not relocatable)<br>
>Version     : 1.6.0.0                                     Vendor: CentOS<br>
>Release     : 0.30.b09.el5                       Build Date: Tue 07      Apr 2009 07:24:52 PM EDT<br>
>Install Date: Thu 11 Jun 2009 03:27:46 PM      EDT      Build Host: <a target="_blank" href="http://builder10.centos.org">builder10.centos.org</a><br>
>Group       :      Development/Languages         Source RPM:      java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm<br>
>Size             : 76336266                              License: GPLv2 with      exceptions<br>
>Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM      EDT, Key ID a8a447dce8562897<br>
>URL         : <a target="_blank" href="http://icedtea.classpath.org/">http://icedtea.classpath.org/</a><br>
>Summary          : OpenJDK Runtime Environment<br>
>Description :<br>
>The OpenJDK      runtime environment.<br>
<div class="im"><br>
> Make sure you haven't missed any exceptions occurring      in other threads.</div>
There are no threads missing in the application      (terminated threads are<br>
not replaced) and there is a try catch pair      (prints error and rethrows)<br>
around the run loop of each thread. It is      possible that an exception may<br>
have been swallowed up somewhere.<br>
<div class="im"><br>
>A small reproducible test case from you would be      useful.</div>
I am working on that. I wrote a test case that mimics the      application's<br>
use of the LBD, but I have not succeeded in reproducing the      problem in<br>
the test case. The app has a single thread (network selector)      that polls<br>
the LBD and several threads (ExecutionSites, and network      threads that<br>
return results from remote ExecutionSites) that offer      results into the<br>
queue. About 120k items will go into/out of the deque      each second. In<br>
the actual app the problem is reproducible but      inconsistent. If I run on<br>
my dual core laptop I can't reproduce it, and      it is less likely to occur<br>
with a small cluster, but with 6 nodes (~560k      transactions/sec) the<br>
problem will usually appear. Sometimes the cluster      will run for several<br>
minutes without issue and other times it will      deadlock immediately.<br>
<br>
Thanks,<br>
<br>
Ariel<br>
<div class="im"><br>
On Wed, 08 Jul 2009 05:14 +1000, "Martin      Buchholz"<br>
<<a href="mailto:martinrb@google.com">martinrb@google.com</a>>      wrote:<br>
>[+core-libs-dev]<br>
><br>
>Doug Lea and I are (slowly)      working on a new version of LinkedBlockingDeque.<br>
>I was not aware of a      deadlock but can vaguely imagine how it might happen.<br>
>A small      reproducible test case from you would be useful.<br>
><br>
>Unfinished      work in progress can be found here:<br>
><a target="_blank" href="http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/BlockingQueue/">http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/</a><br>
><br>
>Martin<br>
 </div>
On      Wed, 08 Jul 2009 05:14 +1000, "David Holmes"<br>
<div class="im"><<a href="mailto:davidcholmes@aapt.net.au">davidcholmes@aapt.net.au</a>>      wrote:<br>
></div>
<div>
<div> </div>
<div class="h5">> Ariel,<br>
><br>
> The poll()ing thread is blocked      waiting for the internal lock, but<br>
> there's<br>
> no indication of      any thread owning that lock. You're using an OpenJDK 6<br>
> build ... can      you try JDK7 ?<br>
><br>
> I don't recall anything similar to this, but      I don't know what version<br>
> that<br>
> OpenJDK6 build relates      to.<br>
><br>
> Make sure you haven't missed any exceptions occurring in      other threads.<br>
><br>
> David Holmes<br>
><br>
> >      -----Original Message-----<br>
> > From: <a href="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</a><br>
>      > [mailto:<a href="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</a>]On      Behalf Of Ariel<br>
> > Weisberg<br>
> > Sent: Wednesday, 8 July      2009 8:31 AM<br>
> > To: <a href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a><br>
>      > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?<br>
>      ><br>
> ><br>
> > Hi all,<br>
> ><br>
> > I did a      search on LinkedBlockingDeque and didn't find anything similar<br>
> >      to what I am seeing. Attached is the stack trace from an application<br>
>      > that is deadlocked with three threads waiting for      0x00002aaab3e91080<br>
> > (threads "ExecutionSite: 26",      "ExecutionSite:27", and "Network<br>
> > Selector"). The execution      sites are attempting to offer results to the<br>
> > deque and the      network thread is trying to poll for them using the<br>
> >      non-blocking version of poll. I am seeing the network thread never<br>
>      > return from poll (straight poll()). Do my eyes deceive me?<br>
>      ><br>
> > Thanks,<br>
> ><br>
> > Ariel Weisberg<br>
>      ><br>
></div>
</div>
</blockquote></div>
<br>
</blockquote> </blockquote></div></body></html>