Hi Peter,
you design pretty much pans out Ok. This is actually similar to the way we
set up our clusters here. Our reasons for separating out the cluster
channels are different (security rather than performance) but the result is
the same.
You might find that you need to use a cluster workload balancing exit to
force the correct choice of cluster.
If you are sending to a cluster queue (a request) and that queue is defined
in only one of the clusters, then you will be fine. If you want to make the
choice based not on the queue, but instead on the message size, then you
will need to open your queues with bind(notfixed) and use the cluster
workload exit to make the choice.
If you are sending a response, based on the replyToQ and replyToQMgr
fields, then either cluster is a valid choice, and the workload balancing
algorithm gets to make the choice. The IBM default algorithm may not be
able to make the choice that you want, in which case you will need to write
or buy a workload balancing exit. This can also happen in an environment
where the destination for a message is looked up in an external database
(like LDAP) and the target queue manager and queue are both specified.
Regards,
Neil Casey.
|---------+------------------------------>
| | "Potkay, Peter M |
| | (PLC, IT)" |
| | <[EMAIL PROTECTED]|
| | RTFORD.COM> |
| | Sent by: MQSeries |
| | List |
| | <[EMAIL PROTECTED]|
| | AC.AT> |
| | |
| | |
| | 15/07/2003 13:09 |
| | Please respond to |
| | MQSeries List |
| | |
|---------+------------------------------>
>--------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: A double cluster to get 2 CLUSRCVR channels?
|
>--------------------------------------------------------------------------------------------------------------|
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
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
