1 Reply Latest reply on Aug 23, 2011 1:58 PM by kogber

    JBoss Messages stuck in Delivering State?

    kogber

      I am trying to diagnose and fix what is likely an environmental problem. We have dev, SI, and production servers, and they have been setup the same for several years. One of the environments has stopped working for a particular JBM Queue, and I have so far been unable to figure out why.

      What I am seeing via the JMX Console is that the messages are "stuck" in the delivering state. The MessageCount and DeliveringCount increment each time a message is sent through the Queue.  They never decrement back to 0, as with the properly functioning environments.  The Consumer's onMessage() is invoked, and it outputs debug messages into the log4j log, however I don't think it ever completes the request.

      This is a persisted JBM setup. Restarting the JBoss Server doesn't help. Clearing out or even dropping the JBM_* tables does not help. 

      The jbm_msg_ref entries have null transaction_id's and the state is 'C', which seems like it was put into this state by the prepared statement "ROLLBACK_MESSAGE_REF2" from the oracle-persistence-service.xml we use.

      The MaxPoolSize for the MDB consumer is 15, and this is also the max amount of messages that are received by the consumer instances. After 15, it seems that the Queue "fills up" and there are no longer any available consumer MBeans to receive messages.

      I am looking for ideas or suggestions about how to diagnose and fix the problem. I've been reaserching for a few days with little results. There are plenty of JIRA tickets for this fairly old version of JBM, but other instances of the same setup work fine, so I suspect that there is some sort of network, race condition, or env issue on this one server/DB combo.

      JBoss Remoting 4.3.0.GA

      JBoss Messaging 1.4.0.SP3

      JBoss 4.3.0.GA

      Thanks!

        • 1. Re: JBoss Messages stuck in Delivering State?
          kogber

          The issue was identified to be caused by Oracle database issues.  The database instance was bounced to resolve the issue.  Most likely, the database performance was slow enough to have caused a timing issue with message acknowledgement.