Author |
Message
|
catwood2 |
Posted: Thu Oct 07, 2004 2:54 pm Post subject: Disabling Cluster Sender Channel |
|
|
Centurion
Joined: 17 May 2002 Posts: 108
|
If I turn off triggering on the SYSTEM.CLUSTER.TRANSMIT.QUEUE is the impact that no sender channel will be created?
We have a testing requirement - to allow the application to service it's input queue and write messages to cluster queues. However, we don't want the messages to actually be sent to the target queue/qmgr. After the test, we would drain the cluster xmit queue. I have been thru the cluster manual and searched some posts and I can't find it stated black and white that the trigger on the xmit queue is what creates the sender channel. And, obviously, I'm on a learning curve with clusters.
thanks for any advice. |
|
Back to top |
|
 |
siliconfish |
Posted: Thu Oct 07, 2004 3:00 pm Post subject: |
|
|
 Master
Joined: 12 Aug 2002 Posts: 203 Location: USA
|
Why don't you SUSPEND tha queue manager from the cluster so that no messages will be sent to that queue manager. _________________ siliconfish |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Oct 07, 2004 8:10 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
siliconfish wrote: |
Why don't you SUSPEND tha queue manager from the cluster so that no messages will be sent to that queue manager. |
That only advises work to not come TO this QM. It does not prevent work from leaving this QM.
CatWood2, I have never tried it, but you could GET_INHIBIT the S.C.T.Q. The channels would not be able to pull the messages then. (I have never dones this to cluster transmit q -do it in TEST first!) Just turning triggering off would prevent new channels from starting, but existing ones would remain running and pulling messages.
Once you reenabled for GETs, it should retrigger automatically. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
siliconfish |
Posted: Thu Oct 07, 2004 8:16 pm Post subject: |
|
|
 Master
Joined: 12 Aug 2002 Posts: 203 Location: USA
|
Peter - I meant SUSPEND the TARGET Queue Manager. Wouldn't it work in his case? _________________ siliconfish |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Oct 07, 2004 8:22 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
No. I used the word "advises" purposly. If the target QM is hsoting the only q in the cluster, the message will still go there to the suspended QM. Suspending a QM is telling the cluster "Don't send me anything if there are other QMs in the cluster that can take this message. But if you have to send it to me (I have the only q, or the message is addressed specifically to me), then I guess I will take it."
The only way of taking a QM out of a cluster so no messages go to it no matter what is to stop the CLUSSRCVR channel. Or end the QM.
SUSPEND is not as strong as people think, but sometimes is just what the doctor ordered. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Nigelg |
Posted: Thu Oct 07, 2004 11:38 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Triggering of cluster channels is not the same as for normal distributed channels, so changing the cluster xmitq TRIGGER attribute has no effect.
You could just try stopping the CLUSSDR channels to STOPPED status. The msgs will stay in the cluster xmitq then, and you can drain them later. |
|
Back to top |
|
 |
|