Message Count when using a Core Bridge

[rnicholson10]

I have noticed some unusual behaviour when using a core bridge concerning message count.

Take two queues A and B which are on two physically different boxes and are connected via a core bridge. If I sent 5 messages to A they are delivered from B as you would expect. Here are the counts from each queue.

QueueA

MessageCount(5)
DeliveringCount(5)
MessagesAdded(5)

QueueB

MessageCount(0)
DeliveringCount(0)
MessagesAdded(5)

What's interesting is that the message count never decreases on QueueA, it will always stay at 5.

I have a test box here that has been running for 3 days which has a message count and delivering count of 375261, even though all it's messages have been delivered successfully across the bridge. I am worried that all of these messages are sitting in memory never having been delivered.

Paging is not configured on these boxes and all messages are sent using auto acknowledge. I would have expected the message count to decrease as soon as delivery was successful?

R.

P.S. Still using Beta5, will test this on CR1 once I get a chance to set it up.

[rnicholson10]

Ok, upgraded to CR1 today and the behaviour is different. The source queue of a bridge will now decrease it's message count every X(ish) number of messages (which is way better than Beta5!).

However if I have a message count of 200 left over from the last confirmation-window-size these will stay in the source queue until another Xish number of messages have been sent across the bridge. Does this matter?

[timfox]

Messages on a bridge get acknowledged at the source every <confirmation-window-size> bytes. So if you just stop sending you may well see unacked messages.

At session close, all the remaining will be flushed and acked, which is what would happen on a clean shutdown.

If the server crashes then they will remain unacked and be resent on reconnect, however this isn't a problem with duplicate detection which will just ignore any previously sent messages.

So it shouldn't be a problem.

Actually, on my list today, I'm adding an ack timeout too. So if messages don't get flushed within a certain timeout they'll get flushed anyway.

[rnicholson10]

Perfect, an ack timeout is exactly what I'm looking for.