MQSeries.net :: View topic

vnreddy · Posted: Mon Apr 04, 2005 7:06 am Post subject:

(Sorry in advance for the long post)

Dear All,

We have a WMQ clustered system that has the concept of a Gateway QM that has applications connecting to it to get access to our messaging HUB

One of the application groups is trying to remove a single point of failure they have for incoming messages into their application from the messaging hub. In future we may need to provide the same kind solution to other applications also to prevent the single point failure.

Here the single point failure is when messaging HUB delivers the messages to a application queue, when the application queue is not recognised as part of HUB Clusters and if the messages are not delivered to the application queue through a remote queue, the messages will stay on transmit queue,rather than be delivered to another queue that would be available.

The following two proposal options are in our discussion:

Option 1: Inviting the Gateway QM into application cluster repository.
In this case, the messages from Gateway queue manager will be delivered to the clustered local queue instead of using remote queue definition. At application end they have three clustered queue managers and having the clustered local queue defined on all the QMs.If one queue manager goes down, the other queue managers can pick up the message from Gateway queue manager and proceeds further

Option 2 : Having one QM on one NT1 machine which has hardware clustered with other NT2 machine. The NT queue manager is in MQ Clustered with the Applications MQ cluster.
In this case, the messaging HUB delivers the messages to NT1 queue manager through Gateway Queue Manager using the remote queue definition, If the NT1 queue manager box goes down , then NT2 machine will take fail over from NT1 box and receive the messages from the Gateway queue manager.

Here, we don't want to put the HUB messaging into risk using the Option 1, as this is because putting the Gateway Queue manager into Application cluster repository can leads us issues with security and administration. And even we don't to invite the Application queue managers into HUB Cluster repository, as this also leads to same security and administration issues.

But at the same we want provide a solution for this, so that in future other applications also can implement the same.

Has anybody experienced this kind of situation? Any experiences on Option 1 and Option 2 ?

Any other good options to achieve the solution.?

It would be great if you can share your any ideas/options on this.

Thanks in Advance

Regards
N Reddy