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.

      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.

        • 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.