We have been experiencing intermittent blocking (everything slows down and then just hangs) in our application. We use JBoss 3.2.0 on the server and SWING clients on customer desktops. I did the thread dump analysis during and after blocking. Looks like we have many threads waiting on JMSDestinationManager:connectionClosing(). Here is a stack trace of one of the waiting thread:

State: waiting for monitor entry

org.jboss.mq.server.JMSDestinationManager:connectionClosing(JMSDestinationManager.java:542)
waiting to lock-->org.jboss.mq.server.JMSDestinationManager(0x92d5f398)
org.jboss.mq.server.JMSServerInterceptorSupport:connectionClosing(JMSServerInterceptorSupport.java:112)
org.jboss.mq.security.ServerSecurityInterceptor:connectionClosing(ServerSecurityInterceptor.java:61)
org.jboss.mq.server.TracingInterceptor:connectionClosing(TracingInterceptor.java:158)
org.jboss.mq.server.JMSServerInvoker:connectionClosing(JMSServerInvoker.java:114)
org.jboss.mq.il.oil.OILServerILService$Client:run(OILServerILService.java:397)
java.lang.Thread:run(Thread.java:534)

And the stack trace of the thread holding the moitor:

State: runnable

java.net.SocketInputStream:socketRead0
java.net.SocketInputStream:read(SocketInputStream.java:129)
java.io.BufferedInputStream:fill(BufferedInputStream.java:183)
java.io.BufferedInputStream:read(BufferedInputStream.java:201)
locked-->java.io.BufferedInputStream(0xa89c47f0)
java.io.ObjectInputStream$PeekInputStream:peek(ObjectInputStream.java:2123)
java.io.ObjectInputStream$BlockDataInputStream:readBlockHeader(ObjectInputStream.java:2303)
java.io.ObjectInputStream$BlockDataInputStream:refill(ObjectInputStream.java:2370)
java.io.ObjectInputStream$BlockDataInputStream:read(ObjectInputStream.java:2442)
java.io.ObjectInputStream$BlockDataInputStream:readByte(ObjectInputStream.java:2591)
java.io.ObjectInputStream:readByte(ObjectInputStream.java:845)
org.jboss.mq.il.oil.OILClientIL:waitAnswer(OILClientIL.java:200)
org.jboss.mq.il.oil.OILClientIL:close(OILClientIL.java:74)
locked-->org.jboss.mq.il.oil.OILClientIL(0xa89c39f0)
org.jboss.mq.server.JMSDestinationManager:connectionClosing(JMSDestinationManager.java:578)
locked-->org.jboss.mq.server.JMSDestinationManager(0x92d5f398)
org.jboss.mq.server.JMSServerInterceptorSupport:connectionClosing(JMSServerInterceptorSupport.java:112)
org.jboss.mq.security.ServerSecurityInterceptor:connectionClosing(ServerSecurityInterceptor.java:61)
org.jboss.mq.server.TracingInterceptor:connectionClosing(TracingInterceptor.java:158)
org.jboss.mq.server.JMSServerInvoker:connectionClosing(JMSServerInvoker.java:114)
org.jboss.mq.il.oil.OILServerILService$Client:run(OILServerILService.java:397)
java.lang.Thread:run(Thread.java:534)

We use non-persistent JMS Queues. I noticed that in addition to the AUTO_ACKNOWLEDGE on the QueueSession:
queueSession = getQueueConnection().createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE),

we are also sending a programmatic acknowledgement:
sendRequest.acknowledge()

Questions:
1. Can multiple acknowledges cause JMSDestinationManager to get confused and result in multiple waiting threads?
2. Is this issue related to a bug reported in JBoss 3.2.8 regarding NPE on JMSDestinationManager.connectionClosing (http://jira.jboss.com/jira/browse/JBAS-2973)? We don't see the NPE in our logs though.

Thanks in advance.

Prabodh Deshmukh