Deadlock in JBoss AS 7.1.0.Final / HornetQ 2.2.11
daokeeff May 1, 2012 5:38 AMHello all,
As part of my internal testing for our product against HornetQ 2.2.11 (embedded in JBoss AS 7.1.0.Final), I recently encountered a deadlock (see attached jstack, the deadlock is near the end, a snippet of which I've inlined below). Initially I thought it was a HornetQ problem, so I posted a query on the HornetQ forum, but the HornetQ devs think it is a JBoss AS 7 problem and suggested I should repost here (see here for my post on the HornetQ forum: https://community.jboss.org/message/733037#733037 ). Can any of you help to confirm whether it is indeed a JBoss AS 7 issue and create an appropriate defect?
Found one Java-level deadlock:
=============================
"pool-5-thread-10":
waiting to lock monitor 0x00002aaabc05d910 (object 0x00000007c69e5560, a org.jboss.remoting3.remote.InboundMessage),
which is held by "Remoting "uxesplxbld11" read-1"
"Remoting "uxesplxbld11" read-1":
waiting to lock monitor 0x00002aaab06223a8 (object 0x00000007c69e5580, a org.xnio.streams.BufferPipeInputStream),
which is held by "pool-5-thread-10"
Java stack information for the threads listed above:
===================================================
"pool-5-thread-10":
at org.jboss.remoting3.remote.InboundMessage.openInboundWindow(InboundMessage.java:128)
- waiting to lock <0x00000007c69e5560> (a org.jboss.remoting3.remote.InboundMessage)
at org.jboss.remoting3.remote.InboundMessage$2.acknowledge(InboundMessage.java:63)
at org.xnio.streams.BufferPipeInputStream.read(BufferPipeInputStream.java:140)
- locked <0x00000007c69e5580> (a org.xnio.streams.BufferPipeInputStream)
at org.jboss.remoting3.remote.InboundMessage$3.read(InboundMessage.java:82)
at java.io.DataInputStream.readByte(DataInputStream.java:248)
at org.jboss.naming.remote.protocol.v1.ReadUtil$1.read(ReadUtil.java:55)
at java.io.InputStream.read(InputStream.java:163)
at java.io.FilterInputStream.read(FilterInputStream.java:116)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at org.jboss.marshalling.SimpleDataInput.readUnsignedByteDirect(SimpleDataInput.java:262)
at org.jboss.marshalling.SimpleDataInput.readUnsignedByte(SimpleDataInput.java:224)
at org.jboss.marshalling.river.RiverUnmarshaller.start(RiverUnmarshaller.java:1186)
at org.jboss.naming.remote.protocol.v1.ReadUtil.prepareForUnMarshalling(ReadUtil.java:64)
at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:109)
at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:70)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
"Remoting "uxesplxbld11" read-1":
at org.xnio.streams.BufferPipeInputStream.pushEof(BufferPipeInputStream.java:112)
- waiting to lock <0x00000007c69e5580> (a org.xnio.streams.BufferPipeInputStream)
at org.jboss.remoting3.remote.InboundMessage.cancel(InboundMessage.java:186)
- locked <0x00000007c69e5560> (a org.jboss.remoting3.remote.InboundMessage)
at org.jboss.remoting3.remote.RemoteConnectionChannel.handleMessageData(RemoteConnectionChannel.java:424)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:234)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
Found 1 deadlock.
Thanks,
Dan.