| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Use of explicit cluster sender channels |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQGrimley |
 Posted: Thu Aug 12, 2004 8:14 am Post subject: Use of explicit cluster sender channels |
 |
|
Novice
Joined: 29 Jun 2004
Posts: 10
|
| Hi. We are running overlapping clusters in a star shape. The two repository managers at the centre of the star are the Full Repository Managers for all clusters. We are running MQ 5.3 on Windows 2K, and are in the process of upgrading to CSD6 / SP4. We have updated one of the Full Repository managers successfully (and all the Partial Repository managers bar one). We started this latest upgrade process by suspending the Full Repository Manager, and waiting a while. It seems that nearly every SYSTEM.CLUSTER.COMMAND.QUEUE and SYSTEM.CLUSTER.TRANSMIT.QUEUE started filling up, and applications were abending. So we backed off from the upgrade. The difference between this Full Repository manager and the other is that this manager is the target of every explicit Cluster Sender Channel, defined when any queue manager joins a cluster. Has anyone an insight into the use of the Explicit sender channel beyond the initial introduction to a cluster? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Aug 12, 2004 8:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
We are running MQ 5.3 on Windows 2K, and are in the process of upgrading to CSD6 / SP4.
|
Go to CSD07. CSD06 has bugs on Windows, which you could fix with Hyper fixes, but why bother.
| Quote: |
Has anyone an insight into the use of the Explicit sender channel beyond the initial introduction to a cluster?
|
They are only used the very first time a QM needs to talk to the FR. Never again. Unless you issue a REFRESH command with REPOS(YES), in which case the local QM thinks its talking to the FR QM for the very first time again.
I doubt this has anything to do with the symptoms you saw.
I have no idea why queues on QM1, QM2 and QM3 would back up if you suspended QM4.
As for the abending applications, why were they abending? Maybe it was just a coincedence.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQGrimley |
| Posted: Fri Aug 13, 2004 6:37 am Post subject: |
|
|
Novice
Joined: 29 Jun 2004
Posts: 10
|
| Thanks for that. It has removed explicit channels from the problem. I have no visibility of the applications, but I now suspect a number have opened queues with BIND ON OPEN. In which case even SUSPEND with the FORCE option will have no effect. I shall have to PUT INHIBIT all application queues on this server before issuing the SUSPEND. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 13, 2004 5:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Which QM are you suspending exactly, and why?
| Quote: |
We have updated one of the Full Repository managers successfully (and all the Partial Repository managers bar one).
|
So the only QM left to upgrade is a Partial Repository (PR).
| Quote: |
We started this latest upgrade process by suspending the Full Repository Manager,
|
Why are you suspending the Full if you are upgrading the partial?
| Quote: |
I shall have to PUT INHIBIT all application queues on this server before issuing the SUSPEND.
|
If you inhibited every clustered queue on a QM, then suspending that QM will do nothing more. No need for that step.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQGrimley |
| Posted: Mon Aug 16, 2004 12:07 am Post subject: |
|
|
Novice
Joined: 29 Jun 2004
Posts: 10
|
| We are upgrading the second Full Repository Manager. After that we will upgrade the last (Partial) manager to complete the roll-out. The two Full Repository Managers are identical in terms of queues. Will we not need to SUSPEND to prevent Repository updates from getting through? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 16, 2004 4:17 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Why do you care if Repository updates "get through"? SUSPEND only says to the cluster "Take me out of the round robin algorithim, but if someone want to send something to me specifically, or I am the only QM that hosts the target queue, I will still take it."
PUT_INHIBITING will take the queues out of the round robin algorithim, unless someone wants to send something to this QM specifically, or it ism the only QM that hosts the target queue. In which case the message will go to the QM and the CLUSRCVR channel will then put it to the DLQ.
The only sure way of preventing traffic from getting to a QM is to STOP the CLUSRCVR channel. Any messages specifically trying to get to this QM will just back up in the S.C.T.Q.s of the other QMs in the cluster until the CLUSRCVR is enabled.
Repository messages are not sprayed throughout the cluster to round robin. They have a definite destination. The FRs, and any PRs that have an active interest in the changed queue. So SUSPENDing a FR is not going to stop messages from going to it 100%.
If it were me, I would do the following:
Run an MS03 on the FR.
Change the FR to a PR.
Stop the CLUSRCVR.
Wait until all the application queues have been drained of outstanding work.
If you are going to save QM data during the upgrade, just go ahead and upgrade.
START the CLUSRCVR when you are back up.
Change the PR back to a FR.
When I upgrade, I like to uninstall and delete the QM, then reinstall fresh and recreate the QM. If you do it this way, follow the instructions in the cluster manual on how to remove a QM from a cluster. Don't worry about messages going to this QM while it is being upgraded. If they have to go to it, they will try, regardless of what you do (by making it a PR you eliminate the need for the vast majority of Admin messages having to come to this QM). And mesages that can go to other QMs will as soon as you bring your QM offline.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQGrimley |
| Posted: Mon Aug 16, 2004 8:51 am Post subject: |
|
|
Novice
Joined: 29 Jun 2004
Posts: 10
|
Thanks Peter. I think that is enough to go on.
_________________
Vince Grimley |
|
| 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
|
|
|
|
