Hi All,<br><br>During our testing we found that sometimes the threadtump identifies the following deadlock:<br><br>Found one Java-level deadlock:<br>=============================<br>"pool-3-thread-16":<br> waiting to lock monitor 0x00124468 (object 0xc15d65e0, a java.lang.Object),<br>
which is held by "New I/O server worker #1-2"<br>"New I/O server worker #1-2":<br> waiting to lock monitor 0x00124348 (object 0xc15d6610, a java.util.LinkedList),<br> which is held by "pool-3-thread-16"<br>
<br>Java stack information for the threads listed above:<br>===================================================<br><br>"pool-3-thread-16":<br> at org.jboss.netty.handler.ssl.SslHandler.wrap(SslHandler.java:477)<br>
- waiting to lock <0xc15d65e0> (a java.lang.Object)<br> - locked <0xc15d6610> (a java.util.LinkedList)<br> at org.jboss.netty.handler.ssl.SslHandler.handleDownstream(SslHandler.java:353)<br> at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:590)<br>
</SNIP><br><br>"New I/O server worker #1-2":<br> at org.jboss.netty.handler.ssl.SslHandler.wrap(SslHandler.java:468)<br> - waiting to lock <0xc15d6610> (a java.util.LinkedList)<br> at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:733)<br>
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:445)<br> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:270)<br> at org.jboss.netty.handler.codec.frame.FrameDecoder.cleanup(FrameDecoder.java:320)<br>
at org.jboss.netty.handler.codec.frame.FrameDecoder.channelDisconnected(FrameDecoder.java:220)<br> at org.jboss.netty.handler.ssl.SslHandler.channelDisconnected(SslHandler.java:369)<br> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:119)<br>
</SNIP><br><br>Some more information:<br>1. JDK Version: 1.5<br>2. OS: Sun Solaris 10.<br>3. Netty version: 3.1.0Beta2<br><br>Any pointers on how to avoid these deadlocks?<br><br>Thanks,<br><br>Virat<br>