| Author |
Message
|
| kirankinnu |
 Posted: Tue Mar 23, 2010 6:56 am Post subject: Changing SYSTEM.BROKER.TIMEOUT.QUEUE |
 |
|
Centurion
Joined: 12 Jun 2004
Posts: 128
Location: Chicago, IL
|
Hello Folks,
I have a design question on timeoutControl and timeoutNotification nodes.
The WebSphere MQ system queue SYSTEM.BROKER.TIMEOUT.QUEUE (defined when a message broker is created) is used to store the timeout messages.
Can we configure the broker to monitor some other queue instead of SYSTEM.BROKER.TIMEOUT.QUEUE . We want to put the queue in a cluster and share it among 2 brokers. So that if one broker is down, the other broker would pick up timeout message. Is it a good design.
Thank you for the support.
Kiran |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Mar 23, 2010 7:09 am Post subject: Re: Changing SYSTEM.BROKER.TIMEOUT.QUEUE |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kirankinnu wrote: |
| Can we configure the broker to monitor some other queue instead of SYSTEM.BROKER.TIMEOUT.QUEUE |
No
| kirankinnu wrote: |
| We want to put the queue in a cluster and share it among 2 brokers. So that if one broker is down, the other broker would pick up timeout message. Is it a good design. |
No, because it's not going to work. Clusters don't share queues. Each queue (of whatever name) is going to be specific to one queue manager and no other queue manager can pick messages out of it.
WMQ Clustering 101.
The only construct that does what you describe is a queue sharing group, which is only supported on z/OS. So if they're z/OS brokers you may have a chance...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 23, 2010 8:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In v7 you can change the queue that a given TimeoutControl/TimeoutNotification Unique Identifier is tied to.
So if you felt a bit masochistic, you *could* define that to be a QALIAS that resolved to a cluster queue.
But that would only cause each individual Timeout Event to show up on one of the two qmgrs.
If you were feeling slightly *more* masochistic, you could define that to be a QALIAS that pointed to a *topic*, which had a subscription on both qmgrs. That would cause each individual Timeout event to appear on *both* of the two qmgrs.
But of course the TimeoutNotification node wouldn't be able to GET from those objects, so the event would never get processed.
You should look at multi-instance brokers or HA brokers if you want reliability in case of failure. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 23, 2010 9:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Could he use zOS with a queue in QSG? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 23, 2010 10:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| Could he use zOS with a queue in QSG? |
As I intimated above
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 23, 2010 10:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| fjb_saper wrote: |
| Could he use zOS with a queue in QSG? |
As I intimated above |
As long as he didn't care which particular broker actually processed the timeout message. In that sense, it's fairly equivalent to using a cluster queue.
If the QSG setup is configured such that the broker/brokers on the other instances of the queue in the QSG are not active except when the "primary" broker is down, then it's fairly equivalent to an HA setup either done with multi-instance or a hardware/software failover. |
|
| Back to top |
|
|
| kirankinnu |
| Posted: Tue Mar 23, 2010 10:59 am Post subject: |
|
|
Centurion
Joined: 12 Jun 2004
Posts: 128
Location: Chicago, IL
|
Thank you for the replies..
We have windows environment, so we would have to drop the idea of Queue Sharing.
With V7 I noticed that we can setup our own timeout queue's, with the cluster setup, we cannot achieve Queue Sharing. So if timeout messages reside on one QMgr, and if that QMgr goes down, there is no way the other Cluster Qmgr gets hold of those messages and continue processing unless if its in HA.
Initially i had some misconception about Clusters but i got it cleared..
Regards,
Kiran |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 23, 2010 11:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kirankinnu wrote: |
| With V7 I noticed that we can setup our own timeout queue's |
Something I've learned about v7 today. Though if I'm reading the InfoCentre correctly it's a qualifier in the name rather than a fully set up name.
Comments anyone?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 23, 2010 11:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| kirankinnu wrote: |
| With V7 I noticed that we can setup our own timeout queue's |
Something I've learned about v7 today. Though if I'm reading the InfoCentre correctly it's a qualifier in the name rather than a fully set up name.
Comments anyone? |
Yes. It's an add on to an existing name rather than the ability to specify a full queue name yourself.
It has some reasonable value, in that it allows you to put a higher volume timeout event stream into it's own queue such that it doesn't cause other event streams to be delayed unnecessarily. |
|
| Back to top |
|
|
|
|
