| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Using clustering for reduced administration |
« View previous topic :: View next topic » |
| Author |
Message
|
| KeeferG |
 Posted: Fri Oct 22, 2004 8:05 am Post subject: Using clustering for reduced administration |
 |
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Please excuse the rambling but I am trying to figure out a system i am to work on.
When using clustering for remote administration and specifying every queue in the cluster (each queue has its own unique name) does the workload algorithm still get called. I assume it does.
We have a workload exit written for all put messages. Does this mean that the workload exit is only called at the recieving end as this is the part doing the puts.
and finally (hoorah) how would the sending application know whether the target system is available as it will need to route to another system if it is not. Can an inquire be done oncluster channels do see if they are up before the message is placed on the transmit queue.
end of ramble.
Thanks
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Sun Oct 24, 2004 11:37 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Yes, the workload algorithm gets called each time a msg is put. The algorithm builds a list of candidate qmgrs to receive the msg, and chooses between them according to the well-known list of criteria that has been posted on this forum several times. Obviously, when there is only one name on the list, that is chosen.
The workload exit gets called at the putting end, not the receiving end. if you have a workload exit, the workload balancing routine is not called.
The cluster qmgr status is also the status of the channel to the qmgr. This is one of the criteria in the workload balancing routine. Note that the routine may choose non-running channel if the only other options score lower.
You can set up a check that the channel is running at the end of a batch by configuring the BATCHHB attribute on the CLUSRCVR. Read about this in the Command Reference manual.
Note that msgs MUST be put BIND_NOT_FIXED for there to be any possibility of them being rerouted.
When a cluster channel stops abnormally, i.e. goes into RETRYING, the msgs on the cluster xmitq for that channel are put through the workload balancer to be rerouted. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Mon Oct 25, 2004 1:38 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Ok. So when an application is putting to the remote cluster queue it gets placed on the transmit queue and our workload exit gets called. With our setup, there is only ever one target queue and i guess therefore one target channel. Our workload exit can only ever get the status of the sending end and therefore not see the channel paused status. As there are no other possible target queue managers in what conditions would the put fail. Channel in stopped status. Any others.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Oct 25, 2004 2:02 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The put never fails unless all the target queues are put disabled; the msg always gets put onto the xmitq. Channel STOPPED or PAUSED is not a reason for the msg not to be put, but those channel statuses are low down the priority:
Class 1: RUNNING INACTIVE
Class 2: BINDING INITIALIZING STARTING STOPPING
Class 3: RETRYING
Class 4: REQUESTING PAUSED STOPPED
The channel statuses in each class are equivalent. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Mon Oct 25, 2004 2:17 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
i guess this means that as long as the queue is put enabled the message will always get placed on the transmit queue regardless of channel status. If the target queue is full the channel will go into paused until all retries have failed then placed on the target qmgr DLQ and if that is full it will just stay on the XMITQ.
I think what we are trying to achieve is to check the status of the channel, if it is running put the message, otherwise put to a different queue on another queue manager. Time for me to investigate our code a bit more I think.
Thanks Nigel
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| 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
|
|
|
|
