2 Replies Latest reply on Nov 13, 2006 10:35 AM by Clebert Suconic

    Failover on QueueBrowser

    Clebert Suconic Master

      When we are failing over a Queue, the server who is taking over the load of that queue will then start to have two Queues.

      In case of a Browser... the Browser will also connect to the new server upon a failure. When this happens we could either use the LocalClusterdQueue on the new server or the original channelID used in the old server.

      So.. I was wondering what would be the correct behavior. I have already committed code on Browser HA recovery considering the fact we will use the LocalQueue. In case we want to use the original failed queue I will have to add the channelID into BrowserState. I have already added the QueueName and MessageSelector string.

      I will write testcases as soon as we define what's the correct behavior.

      Any ideas,

      Clebert Suconic

        • 1. Re: Failover on QueueBrowser
          Tim Fox Master

          There is a certain amount of leeway with QueueBrowsers. The JMS spec doesn't mandate that the browser returns a strict enumeration of all the messages in the queue, and I know that other implementations don't support queue browsers on distributed queues at all, so I would go for active local clustered queue on the new node.

          • 2. Re: Failover on QueueBrowser
            Clebert Suconic Master

            I will go for active local queue (clustered/non-clustered) on the new node. (It is already done BTW) and I will change if someone come up with a valid point to change the implementation later.

            The HA for QueueBrowsers will just open a new browser on the new server and it will replace the objectID to match the new BrowserServerEndpoint.

            I had also to add the destination and the selector expression into BrowserState as I needed that information on the client to recreate the QueueBrowser on the new server.

            Clebert Suconic