ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » routing messages to primary or backup QueueManager

Post new topic  Reply to topic
 routing messages to primary or backup QueueManager « View previous topic :: View next topic » 
Author Message
cynik
PostPosted: Sun Jul 15, 2012 11:57 pm    Post subject: routing messages to primary or backup QueueManager Reply with quote

Newbie

Joined: 31 Mar 2009
Posts: 9

Helo, could you please advise me how to solve this requirement (MQ7):

We have QM A connected to QM B (primary) and QM C (backup). This connection is made via remote queues (let say B.IN and C.IN).

Now I have requirement to route all messages to primary QM B. If connection to QM B goes down, I have to route messages to backup QM C until the B goes up again. I cannot use MQ cluster.

Is there any solution to this request? I was thinking about java application, which will monitor sender channels to B and C and route messages to correct remote queue. But I think this is common MQ scenario and there should be simple solution... Thank you for your advice.
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Jul 16, 2012 12:10 am    Post subject: Re: routing messages to primary or backup QueueManager Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

cynik wrote:
I was thinking about java application, which will monitor sender channels to B and C and route messages to correct remote queue.

By 'queue' I assume you mean 'queue manager'. Why write an app to monitor the channels? Why not use a proper monitoring tool?

cynik wrote:
But I think this is common MQ scenario and there should be simple solution... Thank you for your advice.

The simplest solution is to specify the same XMITQ within the QMA-to-QMB and QMA-to-QMC SDR channels and leave the QMA-to-QMC SDR stopped in 'normal' operation. When you need to cut over, stop the QMA-to-QMB SDR, start the QMA-to-QMC SDR, and reset the sequence number. You'll need a queue manager alias in QMC of course. There are undoubtedly better ways of doing it (I can think of at least one) but the above will at least give you some food for thought.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
stuartjohnston1967
PostPosted: Mon Jul 16, 2012 12:27 am    Post subject: Reply with quote

Novice

Joined: 12 Jul 2010
Posts: 11

I think you should fire your architect

This opens up a larger can of worms, not with standing on how your consuming applications connects and process those messages

Using MQCluster would help you but why don’t you just HA the environment so it will failover correctly without message loss?

I've seen a setup where three queue managers were up and running the connection was based on channel tab files for the client(s)

Feel free to PM me and I'll talk you through some ideas

Stuart
Back to top
View user's profile Send private message Send e-mail
exerk
PostPosted: Mon Jul 16, 2012 12:28 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

stuartjohnston1967 wrote:
Feel free to PM me and I'll talk you through some ideas

PMs have been disabled...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
cynik
PostPosted: Mon Jul 16, 2012 12:57 am    Post subject: Reply with quote

Newbie

Joined: 31 Mar 2009
Posts: 9

thank you for your replies... Problem with this configuration is that we are discussing with big corporation and their requriement is: deliver your messages to QM B, if QM B is down deliver them to QM C. They are not willing to put our QMs into cluster or define some extra configuration for us.. remote queues is all we got. Also I would like to have some automatic solution for this - so no human task is required for switch to backup QM C.

exerk: yes, we use monitoring tool for monitoring. But this is different as I need to route messages based on chanel status. Your solution sounds good, but I have to check with third party if alias on QM C will be acceptable by them.

stuartjohnston1967: I fully agree that MQ cluster or proper HA solution on their side (transparent to us) would be fine... but we have to live with this Channel connection table would be possible solution if we connect to their QM directly via server connection (but we would like to use those remote queues).
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Jul 16, 2012 1:17 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

cynik wrote:
exerk: yes, we use monitoring tool for monitoring. But this is different as I need to route messages based on chanel status.

Your problem will be determining that the channel is not briefly in a non-running state as opposed to a major failure at the receiving end requiring you to switch over. The easy way is to just monitor channels as normal and make it a responsibility of the third-party to inform you that they have had a failure and authorise you to switch connections.

cynik wrote:
Your solution sounds good, but I have to check with third party if alias on QM C will be acceptable by them.

Compromise time - your third-party has imposed this requirement on you and for you to fulfill their requirement without having something that effectively re-routes messages (which would have to change the RQMNAME in the XQH and move the messages to a different XMITQ) your responsibility should be to send messages to their alternative queue manager; their responsibility should then be to handle those messages within that alternative queue manager. Time to start the discussion with them methinks.

cynik wrote:
stuartjohnston1967: I fully agree that MQ cluster or proper HA solution on their side (transparent to us) would be fine... but we have to live with this Channel connection table would be possible solution if we connect to their QM directly via server connection (but we would like to use those remote queues).

Float the idea with them, but I suspect you know the answer already
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Mr Butcher
PostPosted: Mon Jul 16, 2012 2:18 am    Post subject: Reply with quote

Padawan

Joined: 23 May 2005
Posts: 1716

using more than one ip address in the conname of the channel may be one possible (and simple) solution. B first, then C. if B is available for connection, MQ connects to B. If not, MQ connects to C.
As the other end does not seem to be a multi instance qmgr a reset channel may be required (which maybe could be automated).

just a quick thought of a possible solution ....
_________________
Regards, Butcher
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Jul 16, 2012 2:22 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Mr Butcher wrote:
using more than one ip address in the conname of the channel may be one possible (and simple) solution. B first, then C. if B is available for connection, MQ connects to B. If not, MQ connects to C.
As the other end does not seem to be a multi instance qmgr a reset channel may be required (which maybe could be automated).

just a quick thought of a possible solution ....

I stand by my earlier statement of how do you know it's not a brief interruption of the 'normal' channel as opposed to a full switch-over? In any scenario like this I prefer to err on the side of caution and make it a manual and deliberate task to switch over.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Mr Butcher
PostPosted: Mon Jul 16, 2012 3:57 am    Post subject: Reply with quote

Padawan

Joined: 23 May 2005
Posts: 1716

i agree, this procedure should be discussed and agreed on with both ends of the channel......
_________________
Regards, Butcher
Back to top
View user's profile Send private message
cynik
PostPosted: Mon Jul 16, 2012 4:37 am    Post subject: Reply with quote

Newbie

Joined: 31 Mar 2009
Posts: 9

I didnt know that it is possible to add coma separated values to CONNAME, it is nice feature

I will discuss with third party how to determine if switch over is neccesary and hopefully implement some working solution using your advices (with either automatic or manual switch).

Thanks a lot.
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Jul 16, 2012 4:43 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

cynik wrote:
I didnt know that it is possible to add coma separated values to CONNAME, it is nice feature

Introduced with Multi-Instance (MI) queue managers in V7.1

cynik wrote:
I will discuss with third party how to determine if switch over is neccesary and hopefully implement some working solution using your advices (with either automatic or manual switch).

Thanks a lot.

Try not to be railroaded into something that's management intensive for you and management neutral to them - it's got to be mutually acceptable and will involve work by both parties.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » routing messages to primary or backup QueueManager
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.