| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Help needed on MQSeries Intercommunication. |
« View previous topic :: View next topic » |
| Author |
Message
|
| dev |
 Posted: Thu Dec 05, 2002 10:08 am Post subject: Help needed on MQSeries Intercommunication. |
 |
|
Apprentice
Joined: 11 Oct 2001
Posts: 30
|
I have a scenerio where QM A resides on box BOXA and has a RQD named a.rqd which resolves to local queue b.local on QM B, resides on another box BOXB.
Assume if connection from QM A to QM B is not working for a certain time then how can I route it automatically to local queue c.local on QM C residing on box BOXC?
How can I acheive it without clustering, all QMs are on W2K.
Any suggestion would be highly appreciated. |
|
| Back to top |
|
 |
| mgrabinski |
| Posted: Thu Dec 05, 2002 10:46 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Let's assume you have a working connection from A to C.
When you realize that the link from A to B is down, change the 'a.rqd' remote queue definition:
| Code: |
ALTER QR('a.rqd') RQMNAME(QMC)
|
From this moment on, all messages put to a.rqd will be directed to queue manager QMC.
It depends of course on the timing of your reaction the problem - if you don't notice that link A-B is down, messages will be piling on QMB transmission queue.
To overcome this problem, you will need to add some logic to your app and chcange your configuration a little:
- change the QMB transmission queue maxdepth to, say, 10 - when the channel is down, you will very quickly be notified - your puts will fail. If this happens, make your app start puting messages to another remote queue - say, c.rqd, that points to queue manager QMC
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| jhalstead |
| Posted: Fri Dec 06, 2002 3:25 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Hmmm.
As all qmgrs are on differnet boxes they need explicit channels between them, therefore the simple change of the rqmname attrribute won't be enough, this queue is still associated with the transmission queue to the original box. I'd delete the remote queue to the first box and load a new def to the second box. This would reference another transmission queue that is served by another channel.
Another point to consider is that there are some messages stuck on the transmission queue to the original box. Soooo a process needs to be put in place to move these (removing transmission header info etc).
Maybe using a cluster could get around this - oh go on!
Jamie
Last edited by jhalstead on Fri Dec 06, 2002 4:45 am; edited 2 times in total |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Fri Dec 06, 2002 3:51 am Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Jamie,
by
| Quote: |
Let's assume you have a working connection from A to C.
|
I meant proper channels and transmission queue.
I only forgot to say that a new xmitq will be needed in the remote queue definition - thanks for pointing that out.
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
