Dispatched Queue Size

[Michael Black]

I'm trying to figure out this behavior and what I may be doing wrong.

Topic is running on 5.7.0 broker

 

Multi-threaded consumer on a topic using this connection

tcp\://10.2.100.209\:61616?keepAlive=true,jms.prefetchPolicy.all=0

 

I'm testing my app under 2 different machines so I have 2 different topic
queues that contain the same messages.

I should mention both these machines are WAN to the broker so 100ms+ round
trip times are quite possible.even over 1 second at times.

 

I'm doing CLIENT_ACKNOWLEDGE.  Receive msg, process it, then acknowledge it.

 

My situation is that Dispatched Queue Size increments once in a while and
then never decrements below a minimum value EVER.

If I stop and restart the client that queue size stays the same.

But.I have received all the messages and acknowledged them (though like I
said that might've taken a second or more).

 

Right now both clients show receiving and successfully acknowledging 134
messages and the subscribers tab shows this for one client:

Dispatched Queue Size = 2

Dispatched Counter = 134

Enqueued Counter = 134

Dequeue Counter = 132

 

And the other client has 0 queue size and 134 Dequeue as it should

 

I've tried setting the redelivery policy with the thought that 0 means don't
redeliver but I get the same behavior.

                ActiveMQConnectionFactory tcf = new
ActiveMQConnectionFactory(BDQueueConnectString);

                RedeliveryPolicy policy = new RedeliveryPolicy();

                policy.setInitialRedeliveryDelay(10*1000L); // may not need
this if 0 redeliveries works

                policy.setMaximumRedeliveries(0);

 

                tcf.setRedeliveryPolicy(policy);

 

I even tried this:

                tcf.setUseRetroactiveConsumer(true);

But other than sending me 1000 messages from the past the Dispatched Queue
Size still stayed at 2.

 

#1 How do I receive/acknowledge/delete those 2 messages that have been
dispatched again?

#2 How do I stop this behavior where my ack's aren't being processed
correctly apparently.

 

 

 

Michael Black