| Author |
Message
|
| cynik |
 Posted: Sun Jul 15, 2012 11:57 pm Post subject: routing messages to primary or backup QueueManager |
 |
|
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 |
|
 |
| exerk |
| Posted: Mon Jul 16, 2012 12:10 am Post subject: Re: routing messages to primary or backup QueueManager |
|
|
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 |
|
|
| stuartjohnston1967 |
| Posted: Mon Jul 16, 2012 12:27 am Post subject: |
|
|
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 |
|
|
| exerk |
| Posted: Mon Jul 16, 2012 12:28 am Post subject: |
|
|
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 |
|
|
| cynik |
| Posted: Mon Jul 16, 2012 12:57 am Post subject: |
|
|
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 |
|
|
| exerk |
| Posted: Mon Jul 16, 2012 1:17 am Post subject: |
|
|
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 |
|
|
| Mr Butcher |
| Posted: Mon Jul 16, 2012 2:18 am Post subject: |
|
|
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 |
|
|
| exerk |
| Posted: Mon Jul 16, 2012 2:22 am Post subject: |
|
|
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 |
|
|
| Mr Butcher |
| Posted: Mon Jul 16, 2012 3:57 am Post subject: |
|
|
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 |
|
|
| cynik |
| Posted: Mon Jul 16, 2012 4:37 am Post subject: |
|
|
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 |
|
|
| exerk |
| Posted: Mon Jul 16, 2012 4:43 am Post subject: |
|
|
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 |
|
|
|
|
