Weird behaviour of DeliveringCount

[tbuckel]

Hi all

I'm working on a JMS client application that runs inside Glassfish using the HornetQ resource adapter (HornetQ 2.2.5.Final). It uses XA transactions and uses Spring's JMSTemplate with an explicitly cached Connection, Session and MessageConsumer (see application context fragment below) [I can't use MDBs or Spring's DefaultMessageListenerContainer as multiple messages have to be processed in one transaction.]

The client connects to HornetQ 2.2.5.Final running in a JBoss container.

All transactional behaviour (e.g. rollbacks, resends) works fine, but we have noticed an odd behaviour regarding the DeliveringCount: Everytime a new JMS connection is established, the DeliveringCount on the server in increased by a couple of hundred messages. When the consumer stops, the DeliveringCount remains on its old value.

In the client, I tried setting TransactionBatchSize=0 and ClientWindowSize=0 but that did not change anything. No messages are getting redelivered (I thought that was what DeliveringCount stands for - unacknowledged messages) and no message are pushed to the DLQ.

What does this value of DeliveringCount mean and is it any problem or just an "odd value"?

Thanks

Thomas

Configuration of Spring's JMSTemplate:

    <bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">

        <!-- We want to cache the MessageConsumer for performance -->

        <property name="connectionFactory">

            <bean class="org.springframework.jms.connection.CachingConnectionFactory">

                <property name="targetConnectionFactory" ref="databusConnectionFactory" />

                <property name="reconnectOnException" value="false" /> <!-- Not allowed in JEE environment -->

            </bean>

        </property>

        <property name="defaultDestinationName" value="${queueName}"/>

        <property name="sessionTransacted" value="true"/>

        <property name="sessionAcknowledgeModeName" value="SESSION_TRANSACTED"/>

        <property name="messageConverter">

            <bean class="....." />

        </property>

    </bean>

[ataylor]

the delivery count equals the number of messages currently in delivery to clients, this includes messages that are in the clients buffer. The size of the buffer is configured via consumer-window-size

[leosbitto]

Thomas Buckel wrote:

When the consumer stops, the DeliveringCount remains on its old value.

When Spring's ApplicationContext is closed, the method destroy() of CachingConnectionFactory gets called, that closes the shared JMS Connection, which should release all undelivered messages for processing by other clients and decrease DeliveringCount accordingly. So the first needed question seems to be whether your statement "consumer stops" means closing of the ApplicationContext or not.

[tbuckel]

Hi Leos,

The consumer can be manually stopped in the application which closes the current connection of the CachingConnectionFactory.

It might be that this doesn't close everything as it should, but I'm pretty confident that it does.

[tbuckel]

Thanks Andy. I had a read through the docs and it looks like I've mixed up ConsumerWindowSize with ClientWindowSize (??).

Nevertheless I think the DeliveringCount is quite missleading. It shouldn't depend on the ConsumerWIndowSize whether the DeliveringCount recovers or not.

Edit due to retry

[leosbitto]

Thomas Buckel wrote:

Hi Leos,

The consumer can be manually stopped in the application which closes the current connection of the CachingConnectionFactory.

It might be that this doesn't close everything as it should, but I'm pretty confident that it does.

Well, I am pretty confident that calling close() on the Connection which comes from createConnection() of CachingConnectionFactory is not enough. See the Spring documentation for SingleConnectionFactory, which is the parent of CachingConnectionFactory: "A JMS ConnectionFactory adapter that returns the same Connection from all createConnection() calls, and ignores calls to Connection.close()." As I wrote in my previous post, it is needed to call destroy(), which closes the real Connection - see http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jms/connection/SingleConnectionFactory.html#destroy()

[ataylor]

Thanks Andy. I had a read through the docs and it looks like I've mixed up ConsumerWindowSize with ClientWindowSize (??).

Nevertheless I think the DeliveringCount is quite missleading. It shouldn't depend on the ConsumerWIndowSize whether the DeliveringCount recovers or not.

Edit due to retry

I disagree, if a client has 50 messages in its buffer then there are 50 messages in the process of being delivered, makes perfect sense to me.

[tbuckel]

That's correct while the connection is still up Andy, but what I experienced was:

After I closed the consumer/session/connection, the DeliveringCount wasn't reset to what it was before the connection was opened. It remained on a high value.

E.g.

Before my consumer started: MessageCount = 1000, DeliveringCount=0

While my consumer is running: MessageCount=.... , DeliveringCount is > 0 (which is ok)

After my consumer ended: MessageCount = 800, DeliveringCount=120 (which is weird)

Please note that the messages weren't redelivered.

[ataylor]

well like leos said, this is probably something to do with how Spring handles these things.

[tbuckel]

TransactionBatchSize=0 does the job.

Thanks for your help guys.

[shlamalama]

Clarification, trying to find out if this is correct. So delivering count means messages that the client has received, but not acknowledged yet? i.e., a client.receive() will add to my client buffer, and up the delivery count by 1. Then when I do clientMessage.acknowledge(), it will drop delivery count by 1, correct?

[ataylor]

nope, its the number of messages the server has sent to the client, the client has a buffer of messages it holds ready for delivery, once received and acked the count decreases.