3 Replies Latest reply on Dec 9, 2009 7:48 AM by Ross Nicholson

    Message Count when using a Core Bridge

    Ross Nicholson Apprentice

      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.





      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?


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

        • 1. Re: Message Count when using a Core Bridge
          Ross Nicholson Apprentice

          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?

          • 2. Re: Message Count when using a Core Bridge
            Tim Fox Master

            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.

            • 3. Re: Message Count when using a Core Bridge
              Ross Nicholson Apprentice

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