| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Third Party Vendor Supported Workload Exits? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Neil Harvey |
 Posted: Fri May 13, 2005 12:56 pm Post subject: Third Party Vendor Supported Workload Exits? |
 |
|
Newbie
Joined: 08 Nov 2002
Posts: 4
|
We are looking for a workload exit from a third party vendor that will provide geographic affinity. The scenario is really very simple, when putting messages to cluster queues a predefined set of queue managers would be preferred and load balancing should occur across the predefined set. If none of the preferred queue managers were available, load balancing should occur against the remaining queue managers. The list of preferred queue managers is relative to the local queue manager from where the message is being sent and will vary depending upon the geographic location of the local queue manager, so the MC76 exit will not achieve the desired result.
Is anyone aware of a third party vendor that provides this in a productized form with the usually expected support?
We need this capability on Solaris and Windows. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri May 13, 2005 5:00 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you can wait a few weeks, MQ 6.0 will provide this functionality for you right in the base product:
| Quote: |
CLWLPRTY queue attribute
This queue attribute specifies the priority of the queue for the purposes of cluster workload distribution. This parameter is valid only for local, remote, and alias queues. The value must be in the range zero through 9 where zero is the lowest priority and 9 is the highest. Use this attribute to ensure that WebSphere MQ selects some destination queue managers in preference to others with a lower priority. WebSphere MQ selects the destinations with the highest priority before selecting destinations with the lowest cluster destination sequence number (or the most recently used one). Where there are two possible destinations, you can use this attribute to allow one queue manager to act as a failover, if the other queue manager becomes unavailable. In this situation, messages go to the highest priority queue manager until it becomes unavailable, they then go to the next priority queue manager. WebSphere MQ obtains the priority of queue managers after checking channel status. This means that only accessible queue managers are available for selection, and it allows WebSphere MQ to prioritize, where multiple destinations are available. |
This is only 1 of 8 new cluster workload balancing attributes available for QMs, queues and channels. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 13, 2005 6:36 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think that that won't work, Peter.
Because he needs to set priority relative to *each* of his queue managers, not to the network as a whole.
So, from the point of view of QMGR A, QmgrB is higher in priority than QMgrC or QmgrD - BUT from QmgrD, QmgrC is higher than QmgrB.
But I'd think that most workload exits should be configurable to handle this, through manipulation of local properties files.
Without knowing anything about most workload exits - so likely I'm wrong.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat May 14, 2005 6:00 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
OK, I see now what he is after. That's pretty hairy, none of the new attributes will help. I think you're right, and exit on each QM with a different ini file on each server is the only way that I can think of.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Sat May 14, 2005 9:23 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Couldn't this be achieved with overlapping clusters. One "global" cluster and then individual "local" clusters. On the "local" clusters, specify an additional pair of CLUSSDR/CLUSRCVR channels that have a higher NETPRTY.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Sat May 14, 2005 2:32 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Eddie, that sounds like a solution that should be worth testing/investigation....  Let us hear the result....
But anyway it will require a good part of design.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| Neil Harvey |
| Posted: Mon May 16, 2005 8:13 am Post subject: |
|
|
Newbie
Joined: 08 Nov 2002
Posts: 4
|
| jefflowrey wrote: |
I think that that won't work, Peter.
Because he needs to set priority relative to *each* of his queue managers, not to the network as a whole.
So, from the point of view of QMGR A, QmgrB is higher in priority than QMgrC or QmgrD - BUT from QmgrD, QmgrC is higher than QmgrB.
But I'd think that most workload exits should be configurable to handle this, through manipulation of local properties files.
Without knowing anything about most workload exits - so likely I'm wrong. |
I agree that queue priorities wont work. After my original post I reviewed the clustering manual for MQ v6 and discovered the new CLWPRTY channel attribute. The text below comes from the new manual.
To apply a priority factor to a channel for the purposes of cluster workload distribution use the CLWLPRTY attribute. The value must be in the range zero through 9 where zero is the lowest priority and 9 is the highest. This parameter is valid only for channels with a channel type (CHLTYPE) of CLUSSDR or CLUSRCVR. Use this attribute to ensure that WebSphere MQ selects some destination queue managers in preference to others with a lower priority. WebSphere MQ selects the destinations with the highest priority before selecting destinations with the lowest cluster destination sequence number (or the most recently used one). Where there are two possible destinations, you can use this attribute to allow one queue manager to act as a failover, if the other queue manager becomes unavailable. In this situation, messages go to the highest priority queue manager until it becomes unavailable, they then go to the next priority queue manager. WebSphere MQ obtains the priority of queue managers after checking channel status. This means that only accessible queue managers are available for selection, and it allows WebSphere MQ to prioritize, where multiple destinations are available. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon May 16, 2005 8:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Because of the autodefined natured of the cluster channels I'm going to suggest that the channel attribute is also global to the network, not local to a queue manager.
I'm not 100% sure of this, as I don't do a lot of clusters these days and have forgotten how to manually define cluster channels.
Also, I think this starts to defeat the administrative gains of clustering - as you'll have to create channel definitions for a a mostly to fully connected network, in order to get what you need. That is, you'd need to define model channels on each QMGR that had the appropriate CLWPRTY to the correct local set of qmgrs.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 16, 2005 4:09 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Neil, the channel priority is going to work the same way as the queue priority for you (or not work as the case is).
A receiving QM is going to advertise itself at a particular priority, (either because of the CLUSRCVR's priority, or the queue's priority) to all sending QMs the same.
But you need a different priority for each QM. If QMA is sending a message, QM1 is higher priority than QM2. If QMB is sending the messages, QM2 maybe a higher priority than QM1, right? If yes, channel or queue priority in MQ6.0 will both not work the same for you.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
