2 Replies Latest reply on Nov 13, 2006 10:35 AM by clebert.suconic

Failover on QueueBrowser

clebert.suconic Nov 10, 2006 5:33 PM

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

timfox Nov 11, 2006 2:47 AM (in response to clebert.suconic)

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.
Actions
2. Re: Failover on QueueBrowser

clebert.suconic Nov 13, 2006 10:35 AM (in response to clebert.suconic)

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
Actions

Go to original post