| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster question - Peter Potkay |
« View previous topic :: View next topic » |
| Author |
Message
|
| bduncan |
 Posted: Mon Jul 30, 2001 9:23 am Post subject: |
 |
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Hi all,
I posted this question right before the list server went down, but didn't see it show up. My apologies for the double post if the old post shows up with this one.
The goal in my project is to achieve High Availability with workload balancing. We will have several Client applications doing an MQClient connect to a server running the Queue Manager. This one Queue Manager (QM1)
becomes a single point of failure for all the clients, so we are thinking of clustering another Server/Queue Manager (QM2)along with the first one.
The MQ Cluster manual says that you can have more than one instance of a queue within a cluster. Lets say that ReplyQ is both on QM1 and QM2, and there is also a remote definition of RequestQ on both QM1 & QM2, which resolve to QM99 (not in the cluster). Hopefully, client apps will be able to
Client connect to the cluster to put their request message onto RequestQ, an
app connected to QM99 will process that request and generate a reply back to
the cluster, where the original requesting app will find its reply on ReplyQ. I hope that if QM1 goes down, QM2 should pick up the slack as well as handle all reply messages coming back from QM99.
1. When a client app connects to the cluster, what determines which QM it
will connect to, QM1 or QM2? I assume I can achieve balancing when both QM1 and QM2 are up as well as fail over to the one running QM if the other one goes out?
2. If the app codes ReplyQ in the ReplytoQueue field, what gets populated in
the ReplytoQueueManager field? Non-Cluster we leave it blank and the QM fills in its own name. Is the same thing going to happen here, that whichever QM (1 or 2) was lucky enough to get this particular connection
will fill in the reply to field?
3. If the app did connect to 1 particular QM (lets say QM1), and if QM1 filled in its own name in ReplyToQueueManager, what happens to the reply message when it arrives back at the cluster? Will it be found on both
instances of ReplyQ (on QM1 AND QM2)?
4. And the million dollar question, IF the reply message is found on both instances of the ReplyQ, and QM1 goes down for the count after the reply message has arrived but before the app gets it, will any and all apps that were expecting answers on QM1 be able to find them on QM2's ReplyQ??? (Reply
messages will have expiry on them and apps will do a Get by CorrelI-ID)
Peter Potkay
|
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Jul 30, 2001 9:44 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Peter,
1. According to the manual for Clients, an MQCONN call will resolve according to the following rules:
Each example covers a different MQCONN call and gives an explanation of what happens in the specific example presented, by applying the following rules:
I. MQSeries searches the client channel definition table, in channel name order, looking in the queue manager name (QMNAME) field for an entry corresponding to the one given in the MQCONN call.
II. If a match is found the transmission protocol and the associated connection name are extracted.
III. An attempt is made to start the channel to the machine, identified by the connection name (CONNAME). If this is successful, the application will continue. It requires:
a. A listener to be running on the server
b. The listener to be connected to the same queue manager as the one the client wishes to connect to (if specified)
IV. If the attempt to start the channel fails and there is more than one entry in the client channel definition table (in this example there are two entries), the file is searched for a further match. If a match is found, processing continues at step 1.
V. If no match is found, or there are no more entries in the client channel definition table and the channel has failed to start, the application is unable to connect. An appropriate reason code and completion code are returned in the MQCONN call. The application can take action based on the reason and completion codes returned.
So it appears that the client will always connect to QM1 unless QM1 is down.
2. I'm not sure about this one, but I think it behaves like any other situation where if you leave the ReplyToQmgr field blank the queue manager will populate it for you. This definitely needs to be filled in with QM1 or QM2, because if the client connects to QM1 to send the request, we definitely want the reply coming back to QM1, not QM2.
3. You actually need to write you program on the other end (the one that is outside of the cluster and picks up off the request queue) to send the reply queue to the correct reply queue. In other words, it needs to do an MQOPEN of the reply queue on the queue manager specified in the ReplyToQmgr field. In other words, doing an MQOPEN on queue name alone isn't enough. You need to supply the QMGR/Queue Name pair to be able to ensure that your reply is returned to the originating queue manager. If this is done correctly, you should only see a reply on the queue manager that the request came from. However, a simpler way around this is to simply make the Reply queue names machine specific. In other words, call the reply queues something like QM1_REPLY and QM2_REPLY. This way, you simply look at the ReplyToQ name in the message, and do an MQOPEN on that. This way you don't have to worry about queue manager names and possibly sending replies to the wrong queue manager.
4. This shouldn't ever happen because I don't think you want to copies of the reply. If the QMgr that the reply is on goes down, then the Client is stuck waiting.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 30, 2001 11:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Unfortunatly, the CLUSTER manual says nothing about GETs for a situation where you have 2 instances of the same queue in a cluster.Nor do they say anything about replies coming back from outside the cluster. They only talk about Putting to it from within the cluster.
1. I follow you logic and agree that's the way it looks like it would work, except there is no load balancing here. If QM1 is up, it gets all the connections while QM2 watches the grass grow. It does take care of High Availability though because QM2 will be there if QM1 goes down.
2. I would think that it makes sense that whatever QM you were connected to would be the one that fills in its own name in the ReplytoQM field.
3. I am specifically trying to take advantage of the fact that you can have two instances of the same queue on 2 QMs in a cluster, so I don't want to make the names different. My hope is that if QM1 goes down while the reply is being created outside of the cluster, that when it returns to the cluster, it sees that QM1/ReplyQ is no more, but the same queue IS on QM2. Probably not, though, because ReplytoQM will say QM1.
4. I kinda did want 2 copies of the message. By having them expire, copy 2 would go away if the app got it from copy 1. By having the app get by correlid, it shouldnt matter that their were extra copies on the queue from other apps transactions.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Jul 30, 2001 11:56 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
1. I believe you are correct QM2 will watch the grass grow until QM1 becomes unavailable.
2. Under normal circumstances the Queue Manager handling your MQPUT will place its own name in the ReplyToQmgr field if you leave it blank.
3. If you name the two reply queues the same, and do an MQPUT of your reply message, it will workload balance between them and put a SINGLE copy of the message on one of them. If you leave it to fate, you'll have a 50/50 chance of getting it on the correct reply queue. Remember, once your client has issued an MQCONN, it stays with that queue manager for all subsequent MQI calls. Therefore, if the request is handled by QM1, the client is going to be issuing an MQGET on the reply queue that resides on QM1 everytime.
4. Well, to get those two copies of the reply message you are going to explicitly have to make your application that services requests to do 2 MQPUTs of the same message to the two different queue managers QM1 and QM2.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 30, 2001 12:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I tend to agree with what you are saying. It makes sense. The thing that throws me is that the manual says 2 instances of the same queue, not 2 queues that happen to have the same name. I guess I am trying to read something in between the lines. I'm gonna test this out when I have some time and let you know. Also, I am taking an MQ Admin class in Sept, so maybe I can find out more then.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
