2 Replies Latest reply on Jun 2, 2008 10:14 AM by Prabodh Deshmukh

    Intermittent blocking on JBoss 3.2.0 - suspect JMSDestinatio

    Prabodh Deshmukh Newbie

      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