3 QueueManagers (QMs) on 3 servers, QM1, QM2 and QMGateway. QM1 has a CLUSRCVR called TO.QM1.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QM1.CLUSTER2 which is in CLUSTER2. QM1 is a full repository for a cluster name list called CLUSTER1andCLUSTER2.
QM2 has a CLUSRCVR called TO.QM2.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QM2.CLUSTER2 which is in CLUSTER2. QM2 is a full repository for a cluster name list called CLUSTER1andCLUSTER2. QMGateway has a CLUSRCVR called TO.QMGateway.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QMGateway.CLUSTER2 which is in CLUSTER2. The point of all this is so I can have 2 different dynamically created CLUSSNDR channels into each QM. I wish to do this for 2 reasons. First, CLUSTER1 will only have queues and applications that deal with messages greater than 50 MEG in size. CLUSTER2 will only deal with messages smaller than 500 bytes in size (numbers have been exaggerated to make the point). So I would like to insure that the 50MEG lunkers do not block the 500 byte peewees on the CLUSSNDRs as the big messages take their sweet time being sent across. Will my idea work? If I have 2 clusters, I should have 2 channels that should not interfere with each other, correct? I wonder if the fact that there is still only 1 SYSTEM.CLUSTER.TRANSMIT.QUEUE to be shared between the 2 CLUSSNDRs will invalidate this concept (i.e. a message taking its sweet time going down a CLUSSNDR in CLUSTER1 will prevent a little message sitting in the XMIT queue from going down a CLUSSNDR in CLUSTER2.)? Oh yeah, the second (and more important) reason I want to this is the whole concept of how a QM deals with persistent and non persistent messages when it relies on a SAN (remember that thread a little while back titled "How a MQSeries Hub does its thing with persistent / non-persi st m essages"). One of the things we agreed upon was that if both P and NP messages were being sent across a channel, and the receiving side of that channel had a SAN / hard drive outage all the message would start backing up on the sending side. The reason being was that even if the channel speed was FAST, P messages would still need to be logged and if the RCVR was waiting for resources to do that logging, it could not process NP messages either. A way around this is 2 channels. So if I have two CLUSSNDRs going to each QM, and make one of the clusters only NP messages, and the CLUSSNDRs/CLUSRCVRs are set to FAST, then I assume NP messages will not be blocked by P messages waiting to be logged during a SAN blip in the other cluster (but the same QMs). Unless of course the fact that all messages, big and small, persistent and non, queue up in the same SYSTEM.CLUSTER.TRANSMIT.QUEUE. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
