3 Replies Latest reply on Dec 16, 2008 9:59 AM by Adrian Brock

    stale consumer on jboss MQ queue when ThreadPoolFullExceptio

    Srinivasa Mandava Newbie

      Adrian,

      I seen your post regarding the fix for the problem posted at
      http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138726#4138726

      We are seeing this error message in our production and after this error message, the consumer stopped receiving messages. We are trying to reproduce this problem and unable to reproduce. Can you please give me some hint, how I can reproduce this issue?

      It looks like the consumer become stale after this exception occurs. I can see SubscribersCount as 1 and ReceiversCount as 0, after this problem occured and it's not receiving any message.

      SubscribersCount=1
      ReceiversCount=0
      QueueDepth=146615
      Name=StatusQueue


      Thanks,
      Srinivas.

        • 1. Re: stale consumer on jboss MQ queue when ThreadPoolFullExce
          Adrian Brock Master

          As the bug report referenced on the other thread states, it was fixed in 4.2.3.GA
          https://jira.jboss.org/jira/browse/JBAS-5354

          • 2. Re: stale consumer on jboss MQ queue when ThreadPoolFullExce
            Javier García Newbie

            Hi Adrian,

            We are having the same problem with this, but uploading to the new version 4.2.3 GA will be a problem for us, we will have to make all the testing again and it will cost us a lot of time.

            We have discuss the subject and we see two posible ways to solve the problem. The first one is if there is some patch that we can install in a easy way, it means that we don't have to recompile all the system, because it will cost as the same amount of time. Maybe, some easy change that we can make in the jboss server to kill this bug.

            The second conclusion, or the second way that we see to solve the problem is if there is some way to create a Script that can make a periodic checking over the ReceiversCount value, and if it's equal to 0, change it into 1 again, so it will began to work again.

            Thank you.

            • 3. Re: stale consumer on jboss MQ queue when ThreadPoolFullExce
              Adrian Brock Master

               

              "jgmunoz8" wrote:
              Hi Adrian,

              We are having the same problem with this, but uploading to the new version 4.2.3 GA will be a problem for us, we will have to make all the testing again and it will cost us a lot of time.

              We have discuss the subject and we see two posible ways to solve the problem. The first one is if there is some patch that we can install in a easy way, it means that we don't have to recompile all the system, because it will cost as the same amount of time. Maybe, some easy change that we can make in the jboss server to kill this bug.


              The patch is referenced on the JIRA issue. It means replacing one class in jbossmq.jar


              The second conclusion, or the second way that we see to solve the problem is if there is some way to create a Script that can make a periodic checking over the ReceiversCount value, and if it's equal to 0, change it into 1 again, so it will began to work again.

              Thank you.


              Monitoring the receivers count won't help since that regularly goes to zero
              while the consumer is in the process of a receiving message or isn't in a receive()
              at all.

              Changing the receivers count (by re-inserting the receiver into the queue)
              won't help either because you'd still have an unacknowledged message in limbo.

              Disconnecting and reconnecting the client would workaround the problem
              since all unacknowledged messages would be NACKed back into the queue
              when the connection is closed.

              But you've still got the underlying problem that there is a thread somewhere
              which is in an interrupted state and the oswego concurrent thread pool executor
              doesn't like that.