STOMP messages stuck delivering indefinitely

[marrrck]

Hello Everyone,

I'm using Jboss As 7.1.3.Final with pretty much the out-of-the-box configuration of HornetQ 2.2.21.Final (standalone-full-ha.xml configuration), and I'm seeing an itermittent issue with remote stomp clients that are consuming messages from the server. I'm using a jms queue to post message that are picked up via STOMP by remote consumers that are looking for a specific message selector. As my application runs, it seems like the delivering-count on the queue slowly climbs and never goes down that much. For example, last night I had a delivering-count of over 200 for hours. I'm assuming this is because the client is not sending an ACK for the message?

My question is, why aren't these rolled back or timed out eventually? The connection is not being timed out, so the client must be keeping it alive and sending data to the server (just not that ACK). I know there is a call-timeout property on the connection factory that should time out unacknowledged messages, but I'm not clear on which connection factory is being used by remote stomp subscribers. The RemoteConnectionFactory has a call timeout of 30000 ms, but the messages don't seem to be timing out. Unless they are just timing out-retrying-timeing out in an infinite loop.

Any ideas for configuration changes I can make to make sure that unacked messages are rolled back or expired after a short time so they won't be stuck deliverying forever?

Thanks in advance for any suggestions or advice you have about this.

[gaohoward]

If the client don't send back 'ACK' the message won't be considered as 'delivered', so the delivering count won't decrease for each of such un-acked message.  Stomp clients don't use any (jms) connection factories.

[marrrck]

Thanks for the Reply!

So what happens to the message that is never ACK'd? Does it ever stop waiting for an ACK message? Also, is the consumer tied up waiting for the ACK? I am seeing this message a lot in my logs when my delivering-count keeps steadily increasing

16:00:18,311 DEBUG [org.hornetq.core.server.impl.QueueImpl] (Thread-4 (HornetQ-server-HornetQServerImpl::serverUUID=723e04c3-ccb5-11e2-ba73-c77d31915799-1529650781)) QueueImpl[name=jms.queue.mm.to, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=723e04c3-ccb5-11e2-ba73-c77d31915799]]@7b7b3da0 doing deliver. messageReferences=15

16:00:18,312 DEBUG [org.hornetq.core.server.impl.QueueImpl] (Thread-4 (HornetQ-server-HornetQServerImpl::serverUUID=723e04c3-ccb5-11e2-ba73-c77d31915799-1529650781)) QueueImpl[name=jms.queue.mm.to, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=723e04c3-ccb5-11e2-ba73-c77d31915799]]@7b7b3da0::All the consumers were busy, giving up now