You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2006/11/24 19:33:37 UTC
Thread Dump for TCK test hang
Hi Folks,
For some reason the closing connection part seems to trigger the hang state
Here is the output from the console immediately prior to the hang sate
[java] TRACE: closing connection
[java] (client.AMQSession 143 ) Dispatcher thread
terminating for channel 1
[java] (handler.ChannelCloseOkMethodHandler 42 ) Received
channel-close-ok for channel-id 1
[java] (protocol.AMQProtocolHandler 170 ) Session closed called
by client
[java] (protocol.AMQProtocolHandler 215 ) Protocol Session [
org.apache.qpid.client.protocol.AMQProtocolHandler@7b6889] closed
----------------------------------------------------------------------------------------------------------------------------------------------
Here is details from the server side logs
2006-11-24 13:26:24,404 INFO [pool-112-thread-3]
handler.ConnectionCloseMethodHandler (ConnectionCloseMethodHandler.java:55)
- ConnectionClose received with reply code/reply text 200/JMS client is
closing the connection. for AMQProtocolSession(/0:0:0:0:0:0:0:1:46996)
2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0]
protocol.AMQPFastProtocolHandler (AMQPFastProtocolHandler.java:135) -
Protocol Session closed
2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0]
pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
PoolingFilter AsynchronousWriteFilter
2006-11-24 13:26:24,407 INFO [SocketAcceptorIoProcessor-0.0]
pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
PoolingFilter AsynchronousReadFilter
---------------------------------------------------------------------------------------------------------------------------------------------
Here is an excerpt from the Thread Dump
I have highlighted the line which says blocking for frame, further down the
stack u can see it's triggered by the AMQSession.close()
[java] "main" prio=1 tid=0x098b3808 nid=0x185b in Object.wait()
[0xbfb68000..0xbfb68df8]
[java] at java.lang.Object.wait(Native Method)
[java] - waiting on <0x88bebfd0> (a java.lang.Object)
[java] at java.lang.Object.wait(Object.java:474)
[java] at
org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(
BlockingMethodFrameListener.java:97)
[java] - locked <0x88bebfd0> (a java.lang.Object)
[java] at
org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply
(AMQProtocolHandler.java:421)
[java] at
org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(
AMQProtocolHandler.java:439)
[java] at org.apache.qpid.client.AMQSession.close(AMQSession.java
:475)
[java] - locked <0x890b7358> (a java.lang.Object)
[java] at org.apache.qpid.client.AMQQueueSessionAdaptor.close(
AMQQueueSessionAdaptor.java:122)
[java] at
com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.cleanup(
MsgSelectorQueueTests.java:194)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at com.sun.ts.lib.harness.EETest.run(EETest.java:502)
[java] at com.sun.ts.lib.harness.ServiceEETest.run(
ServiceEETest.java:74)
[java] at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java
:376)
[java] at com.sun.ts.lib.harness.ServiceEETest.run(
ServiceEETest.java:174)
[java] at
com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.main(
MsgSelectorQueueTests.java:52)
[java] "VM Thread" prio=1 tid=0x098efaf0 nid=0x185e runnable
[java] "VM Periodic Task Thread" prio=1 tid=0x098fd420 nid=0x1864
waiting on condition
Regards,
Rajith
Re: Thread Dump for TCK test hang
Posted by Robert Greig <ro...@gmail.com>.
On 26/11/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> You have to use a private list that only contains folks who have signed the NDA.
When we were signing the NDA I asked Geir Magnusson about this:
Robert Greig asked:
> Does this mean we cannot raise any Jiras relating to CTS failures and
> explicitly mention that they cause the CTS to fail? What about test
> cases (e.g. junit test cases) that exist because of knowledge of
> failure of particular tests?
Geir Magnusson replied:
> You can report failures, but don't be putting source code from the TCK
> into the JIRAs :)
Given that Jiras are public unless we restrict them, reporting
failures on qpid-dev is the same as raising them in Jira.
Does anyone have a copy of the TCK licence agreement?
RG
Re: Thread Dump for TCK test hang
Posted by Hiram Chirino <hi...@hiramchirino.com>.
You have to use a private list that only contains folks who have signed the NDA.
On 11/25/06, Rajith Attapattu <ra...@gmail.com> wrote:
> Hmmm .... I thought u can disucss the test failures on the list, but u can't
> test (or have access) unless you sign the NDA.
> So Hiram since u have done this before with ActiveMQ, how do u handle this
> situation ?
>
> Any suggestions on how we can we discuss test failiures w/o violating the
> NDA ?
>
> Regards,
>
> Rajith
>
> On 11/25/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> >
> > Um. I thought TCK testing was supposed to be done under NDA?? And if
> > so.. why is it being discussed on public list?
> >
> > On 11/24/06, Rajith Attapattu <ra...@gmail.com> wrote:
> > > Hi Folks,
> > >
> > > For some reason the closing connection part seems to trigger the hang
> > state
> > >
> > > Here is the output from the console immediately prior to the hang sate
> > > [java] TRACE: closing connection
> > > [java] ( client.AMQSession 143 ) Dispatcher
> > thread
> > > terminating for channel 1
> > > [java] (handler.ChannelCloseOkMethodHandler 42 )
> > > Received channel-close-ok for channel-id 1
> > > [java] (protocol.AMQProtocolHandler 170 ) Session closed
> > > called by client
> > > [java] (protocol.AMQProtocolHandler 215 ) Protocol Session
> > > [org.apache.qpid.client.protocol.AMQProtocolHandler@7b6889]
> > > closed
> > >
> > >
> > ----------------------------------------------------------------------------------------------------------------------------------------------
> > > Here is details from the server side logs
> > >
> > > 2006-11-24 13:26:24,404 INFO [pool-112-thread-3]
> > > handler.ConnectionCloseMethodHandler
> > > (ConnectionCloseMethodHandler.java:55) - ConnectionClose
> > > received with reply code/reply text 200/JMS client is closing the
> > > connection. for AMQProtocolSession(/0:0:0:0:0:0:0:1:46996)
> > > 2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0]
> > > protocol.AMQPFastProtocolHandler
> > > (AMQPFastProtocolHandler.java:135) - Protocol Session closed
> > > 2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0 ]
> > > pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
> > > PoolingFilter AsynchronousWriteFilter
> > > 2006-11-24 13:26:24,407 INFO [SocketAcceptorIoProcessor-0.0]
> > > pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
> > > PoolingFilter AsynchronousReadFilter
> > >
> > >
> > ---------------------------------------------------------------------------------------------------------------------------------------------
> > > Here is an excerpt from the Thread Dump
> > > I have highlighted the line which says blocking for frame, further down
> > the
> > > stack u can see it's triggered by the AMQSession.close()
> > >
> > > [java] "main" prio=1 tid=0x098b3808 nid=0x185b in Object.wait()
> > > [0xbfb68000..0xbfb68df8]
> > > [java] at java.lang.Object.wait(Native Method)
> > > [java] - waiting on <0x88bebfd0> (a java.lang.Object)
> > > [java] at java.lang.Object.wait(Object.java:474)
> > > [java] at
> > >
> > org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(
> > BlockingMethodFrameListener.java
> > > :97)
> > > [java] - locked <0x88bebfd0> (a java.lang.Object)
> > > [java] at
> > >
> > org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply
> > (AMQProtocolHandler.java:421)
> > > [java] at
> > > org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(
> > AMQProtocolHandler.java:439)
> > > [java] at
> > > org.apache.qpid.client.AMQSession.close(AMQSession.java:475)
> > > [java] - locked <0x890b7358> (a java.lang.Object)
> > > [java] at
> > > org.apache.qpid.client.AMQQueueSessionAdaptor.close(
> > AMQQueueSessionAdaptor.java:122)
> > > [java] at
> > > com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.cleanup(
> > MsgSelectorQueueTests.java
> > > :194)
> > > [java] at
> > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > [java] at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(
> > NativeMethodAccessorImpl.java:39)
> > > [java] at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke
> > > (DelegatingMethodAccessorImpl.java:25)
> > > [java] at java.lang.reflect.Method.invoke(Method.java:585)
> > > [java] at
> > > com.sun.ts.lib.harness.EETest.run(EETest.java:502)
> > > [java] at com.sun.ts.lib.harness.ServiceEETest.run
> > > (ServiceEETest.java:74)
> > > [java] at
> > > com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:376)
> > > [java] at
> > > com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:174)
> > > [java] at
> > > com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.main
> > > (MsgSelectorQueueTests.java:52)
> > > [java] "VM Thread" prio=1 tid=0x098efaf0 nid=0x185e runnable
> > > [java] "VM Periodic Task Thread" prio=1 tid=0x098fd420 nid=0x1864
> > > waiting on condition
> > >
> > > Regards,
> > >
> > > Rajith
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Thread Dump for TCK test hang
Posted by Rajith Attapattu <ra...@gmail.com>.
Hmmm .... I thought u can disucss the test failures on the list, but u can't
test (or have access) unless you sign the NDA.
So Hiram since u have done this before with ActiveMQ, how do u handle this
situation ?
Any suggestions on how we can we discuss test failiures w/o violating the
NDA ?
Regards,
Rajith
On 11/25/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> Um. I thought TCK testing was supposed to be done under NDA?? And if
> so.. why is it being discussed on public list?
>
> On 11/24/06, Rajith Attapattu <ra...@gmail.com> wrote:
> > Hi Folks,
> >
> > For some reason the closing connection part seems to trigger the hang
> state
> >
> > Here is the output from the console immediately prior to the hang sate
> > [java] TRACE: closing connection
> > [java] ( client.AMQSession 143 ) Dispatcher
> thread
> > terminating for channel 1
> > [java] (handler.ChannelCloseOkMethodHandler 42 )
> > Received channel-close-ok for channel-id 1
> > [java] (protocol.AMQProtocolHandler 170 ) Session closed
> > called by client
> > [java] (protocol.AMQProtocolHandler 215 ) Protocol Session
> > [org.apache.qpid.client.protocol.AMQProtocolHandler@7b6889]
> > closed
> >
> >
> ----------------------------------------------------------------------------------------------------------------------------------------------
> > Here is details from the server side logs
> >
> > 2006-11-24 13:26:24,404 INFO [pool-112-thread-3]
> > handler.ConnectionCloseMethodHandler
> > (ConnectionCloseMethodHandler.java:55) - ConnectionClose
> > received with reply code/reply text 200/JMS client is closing the
> > connection. for AMQProtocolSession(/0:0:0:0:0:0:0:1:46996)
> > 2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0]
> > protocol.AMQPFastProtocolHandler
> > (AMQPFastProtocolHandler.java:135) - Protocol Session closed
> > 2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0 ]
> > pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
> > PoolingFilter AsynchronousWriteFilter
> > 2006-11-24 13:26:24,407 INFO [SocketAcceptorIoProcessor-0.0]
> > pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
> > PoolingFilter AsynchronousReadFilter
> >
> >
> ---------------------------------------------------------------------------------------------------------------------------------------------
> > Here is an excerpt from the Thread Dump
> > I have highlighted the line which says blocking for frame, further down
> the
> > stack u can see it's triggered by the AMQSession.close()
> >
> > [java] "main" prio=1 tid=0x098b3808 nid=0x185b in Object.wait()
> > [0xbfb68000..0xbfb68df8]
> > [java] at java.lang.Object.wait(Native Method)
> > [java] - waiting on <0x88bebfd0> (a java.lang.Object)
> > [java] at java.lang.Object.wait(Object.java:474)
> > [java] at
> >
> org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(
> BlockingMethodFrameListener.java
> > :97)
> > [java] - locked <0x88bebfd0> (a java.lang.Object)
> > [java] at
> >
> org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply
> (AMQProtocolHandler.java:421)
> > [java] at
> > org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(
> AMQProtocolHandler.java:439)
> > [java] at
> > org.apache.qpid.client.AMQSession.close(AMQSession.java:475)
> > [java] - locked <0x890b7358> (a java.lang.Object)
> > [java] at
> > org.apache.qpid.client.AMQQueueSessionAdaptor.close(
> AMQQueueSessionAdaptor.java:122)
> > [java] at
> > com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.cleanup(
> MsgSelectorQueueTests.java
> > :194)
> > [java] at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [java] at
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
> > [java] at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMethodAccessorImpl.java:25)
> > [java] at java.lang.reflect.Method.invoke(Method.java:585)
> > [java] at
> > com.sun.ts.lib.harness.EETest.run(EETest.java:502)
> > [java] at com.sun.ts.lib.harness.ServiceEETest.run
> > (ServiceEETest.java:74)
> > [java] at
> > com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:376)
> > [java] at
> > com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:174)
> > [java] at
> > com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.main
> > (MsgSelectorQueueTests.java:52)
> > [java] "VM Thread" prio=1 tid=0x098efaf0 nid=0x185e runnable
> > [java] "VM Periodic Task Thread" prio=1 tid=0x098fd420 nid=0x1864
> > waiting on condition
> >
> > Regards,
> >
> > Rajith
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
Re: Thread Dump for TCK test hang
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Um. I thought TCK testing was supposed to be done under NDA?? And if
so.. why is it being discussed on public list?
On 11/24/06, Rajith Attapattu <ra...@gmail.com> wrote:
> Hi Folks,
>
> For some reason the closing connection part seems to trigger the hang state
>
> Here is the output from the console immediately prior to the hang sate
> [java] TRACE: closing connection
> [java] ( client.AMQSession 143 ) Dispatcher thread
> terminating for channel 1
> [java] (handler.ChannelCloseOkMethodHandler 42 )
> Received channel-close-ok for channel-id 1
> [java] (protocol.AMQProtocolHandler 170 ) Session closed
> called by client
> [java] (protocol.AMQProtocolHandler 215 ) Protocol Session
> [org.apache.qpid.client.protocol.AMQProtocolHandler@7b6889]
> closed
>
> ----------------------------------------------------------------------------------------------------------------------------------------------
> Here is details from the server side logs
>
> 2006-11-24 13:26:24,404 INFO [pool-112-thread-3]
> handler.ConnectionCloseMethodHandler
> (ConnectionCloseMethodHandler.java:55) - ConnectionClose
> received with reply code/reply text 200/JMS client is closing the
> connection. for AMQProtocolSession(/0:0:0:0:0:0:0:1:46996)
> 2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0]
> protocol.AMQPFastProtocolHandler
> (AMQPFastProtocolHandler.java:135) - Protocol Session closed
> 2006-11-24 13:26:24,406 INFO [SocketAcceptorIoProcessor-0.0 ]
> pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
> PoolingFilter AsynchronousWriteFilter
> 2006-11-24 13:26:24,407 INFO [SocketAcceptorIoProcessor-0.0]
> pool.PoolingFilter (PoolingFilter.java:182) - Destroy called on
> PoolingFilter AsynchronousReadFilter
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
> Here is an excerpt from the Thread Dump
> I have highlighted the line which says blocking for frame, further down the
> stack u can see it's triggered by the AMQSession.close()
>
> [java] "main" prio=1 tid=0x098b3808 nid=0x185b in Object.wait()
> [0xbfb68000..0xbfb68df8]
> [java] at java.lang.Object.wait(Native Method)
> [java] - waiting on <0x88bebfd0> (a java.lang.Object)
> [java] at java.lang.Object.wait(Object.java:474)
> [java] at
> org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(BlockingMethodFrameListener.java
> :97)
> [java] - locked <0x88bebfd0> (a java.lang.Object)
> [java] at
> org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:421)
> [java] at
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:439)
> [java] at
> org.apache.qpid.client.AMQSession.close(AMQSession.java:475)
> [java] - locked <0x890b7358> (a java.lang.Object)
> [java] at
> org.apache.qpid.client.AMQQueueSessionAdaptor.close(AMQQueueSessionAdaptor.java:122)
> [java] at
> com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.cleanup(MsgSelectorQueueTests.java
> :194)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> [java] at java.lang.reflect.Method.invoke(Method.java:585)
> [java] at
> com.sun.ts.lib.harness.EETest.run(EETest.java:502)
> [java] at com.sun.ts.lib.harness.ServiceEETest.run
> (ServiceEETest.java:74)
> [java] at
> com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:376)
> [java] at
> com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:174)
> [java] at
> com.sun.ts.tests.jms.ee.all.selectorQueue.MsgSelectorQueueTests.main
> (MsgSelectorQueueTests.java:52)
> [java] "VM Thread" prio=1 tid=0x098efaf0 nid=0x185e runnable
> [java] "VM Periodic Task Thread" prio=1 tid=0x098fd420 nid=0x1864
> waiting on condition
>
> Regards,
>
> Rajith
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Thread Dump for TCK test hang
Posted by Martin Ritchie <ri...@apache.org>.
On 27/11/06, Gordon Sim <gs...@redhat.com> wrote:
> Rajith Attapattu wrote:
> > Here is details from the server side logs
> >
> > 2006-11-24 13:26:24,404 INFO [pool-112-thread-3]
> > handler.ConnectionCloseMethodHandler
> > (ConnectionCloseMethodHandler.java:55) - ConnectionClose received with
> > reply code/reply text 200/JMS client is closing the connection. for
> [...]
> > Here is an excerpt from the Thread Dump
> > I have highlighted the line which says blocking for frame, further down
> > the stack u can see it's triggered by the AMQSession.close()
> >
> > [java] "main" prio=1 tid=0x098b3808 nid=0x185b in Object.wait()
> > [0xbfb68000..0xbfb68df8]
> > [java] at java.lang.Object.wait(Native Method)
> > [java] - waiting on <0x88bebfd0> (a java.lang.Object)
> > [java] at java.lang.Object.wait(Object.java:474)
> > [java] at
> > org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(BlockingMethodFrameListener.java
> > :97)
> > [java] - locked <0x88bebfd0> (a java.lang.Object)
> > [java] at
> > org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:421)
> > [java] at
> > org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:439)
> > [java] at
> > org.apache.qpid.client.AMQSession.close(AMQSession.java:475)
> > [java] - locked <0x890b7358> (a java.lang.Object)
> > [java] at
> > org.apache.qpid.client.AMQQueueSessionAdaptor.close(AMQQueueSessionAdaptor.java:122)
> > [java] at
>
>
> The main thread is blocked waiting for a response to the channel close
> issued. That will never come as the server seems to already have closed
> the connection.
>
> I suspect the root of the problem is that AMQSession.close() doesn't
> check whether it is already closed before going through the shutdown
> routine. The AMQQueueSessionAdaptor above is calling close on the
> session as part of cleanup, but the connection (and hence all the
> sessions) have already been closed by an earlier operation.
>
I've just commited a fix for this.
--
Martin Ritchie
Re: Thread Dump for TCK test hang
Posted by Gordon Sim <gs...@redhat.com>.
Rajith Attapattu wrote:
> Here is details from the server side logs
>
> 2006-11-24 13:26:24,404 INFO [pool-112-thread-3]
> handler.ConnectionCloseMethodHandler
> (ConnectionCloseMethodHandler.java:55) - ConnectionClose received with
> reply code/reply text 200/JMS client is closing the connection. for
[...]
> Here is an excerpt from the Thread Dump
> I have highlighted the line which says blocking for frame, further down
> the stack u can see it's triggered by the AMQSession.close()
>
> [java] "main" prio=1 tid=0x098b3808 nid=0x185b in Object.wait()
> [0xbfb68000..0xbfb68df8]
> [java] at java.lang.Object.wait(Native Method)
> [java] - waiting on <0x88bebfd0> (a java.lang.Object)
> [java] at java.lang.Object.wait(Object.java:474)
> [java] at
> org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(BlockingMethodFrameListener.java
> :97)
> [java] - locked <0x88bebfd0> (a java.lang.Object)
> [java] at
> org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:421)
> [java] at
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:439)
> [java] at
> org.apache.qpid.client.AMQSession.close(AMQSession.java:475)
> [java] - locked <0x890b7358> (a java.lang.Object)
> [java] at
> org.apache.qpid.client.AMQQueueSessionAdaptor.close(AMQQueueSessionAdaptor.java:122)
> [java] at
The main thread is blocked waiting for a response to the channel close
issued. That will never come as the server seems to already have closed
the connection.
I suspect the root of the problem is that AMQSession.close() doesn't
check whether it is already closed before going through the shutdown
routine. The AMQQueueSessionAdaptor above is calling close on the
session as part of cleanup, but the connection (and hence all the
sessions) have already been closed by an earlier operation.