| Author |
Message
|
| webspherical |
 Posted: Wed Dec 14, 2005 4:44 pm Post subject: messaging contingency |
 |
|
Acolyte
Joined: 15 Aug 2005
Posts: 50
|
IF messages that are being put on a remote qDef start piling up. lets say a channel is down or the remote qmgr is down, is it possible to have a pgm that can determine the qdepth is too high read the messages off and put them into a different remote queue to send them elsewhere?
the messages would be in a xmit queue though right? isnt this an issue as it has the xmit header on it, not to mention xmit q's are usually get inhibited.
thanks for any input. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Wed Dec 14, 2005 4:52 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Have a look at the MQ V6 clustering features. You can set up clustering so if one queue manager goes down, clustering will send the messages to an alternate.
_________________
-wayne |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Dec 14, 2005 5:33 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| not to mention xmit q's are usually get inhibited |
I would hope not. If they are, then the Channel MCA's wouldn't be able to GET the messages to transmit. They are just MQ applications, after all.
I'm guessing you really mean Open Exclusive.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| webspherical |
| Posted: Wed Dec 14, 2005 7:44 pm Post subject: |
|
|
Acolyte
Joined: 15 Aug 2005
Posts: 50
|
| so it is possible to just have another mq pgm read all the messages off that queue and write them to another remote queue. (no cluster stuff) |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Dec 14, 2005 7:58 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Yes, of course you can write a program to get the messages off the xmit queue and re-queue them onto other remote queues. But, there is quite a bit of coding and testing involved, a good deal of system work to figure out what xmit q's need to be monitored, how to figure out when the queue is too deep because the channel is down versus a lot of messages have just been dumped on the xmitq.
If it were me, I'd opt for the clustering solution, because that is the MQ architected way of doing what you want to do.
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 15, 2005 7:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| EddieA wrote: |
| Quote: |
| not to mention xmit q's are usually get inhibited |
I would hope not. If they are, then the Channel MCA's wouldn't be able to GET the messages to transmit. They are just MQ applications, after all.
I'm guessing you really mean Open Exclusive.
Cheers, |
When the channel is retrying, the XMITQ is in fact get inhibited.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
