| Author |
Message
|
| hilltops |
 Posted: Thu Sep 07, 2006 9:09 am Post subject: Queue manager affinity with intercepting load-balancer |
 |
|
Centurion
Joined: 01 Mar 2006
Posts: 112
|
I am currently designing an MQ infrastructure that consists of a client application communicating via MQI channels to MQ server layer, which is made of a number of overlapping clusters. The gateway into the cluster consists of two servers each hosting a queue manager. Client applications would connect using MQI to these gateway queue managers.
Complexity creeps in because we want to put in a network load-balancer (such as gcc or css) in front of the gateway queue managers to distribute the load to the queue managers. Consequently, the applications requesting access to the gateway would not know in advance which queue manager they will be directed to. This decision will be made by the load-balancer.
For simple datagrams type message, this does not present a problem. However, for request-response where the application would be waiting for a response on a named queue, it is important that the response is delivered to the queue manager to which the application is connected.
My question is: How does one maintain such message affinity? The responding application may well sit behind several layer of queue managers and we want the responding application to target the queue manager that sending application is connected to.
The topology looks something like this;
Sending App -> GCC -> GatewayQMs -> QM1-> QM2 -> QM3 ->Resp App
Thankx |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Sep 07, 2006 9:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A proper implementation of the Request/Reply pattern will maintain this "affinity" by making use of the ReplyToQueue and ReplyToQueueManager fields of the MQ header.
Maybe you should review the Application Programming Guide.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hilltops |
| Posted: Fri Sep 08, 2006 6:48 am Post subject: |
|
|
Centurion
Joined: 01 Mar 2006
Posts: 112
|
To use the ReplyToQueue and ReplyToQueuemanager fields imply that you know the queue manager you want the reply to be sent to. So this information is set when the request is sent.
But my problem is that the load-balancer picks one of the queue managers and binds to that one. The application would expect the reply to come to that queue manager picked by the load-balancer. Of course, without the load-balancer in front of the queue managers, it's a trivial problem. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Sep 08, 2006 6:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The requesting application will still know which queue manager it is connected to, after it is connected.
Even if it has to explicitly issue an Inquire Queue Manager to find out.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Sep 11, 2006 12:13 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The ReplyToQMgr field is automatically completed by the qmgr when the msg is put, so the app does not need to know which qmgr it is connected to.
That said, how can it not know? It has to supply a qmgr name to MQCONN.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Sep 11, 2006 3:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQClient apps do not have to supply a QM name in order to connect.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Sep 12, 2006 10:45 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
| MQClient apps do not have to supply a QM name in order to connect. |
you mean when using a client channel table? (the QMname is in the Client Channel Definition)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bbburson |
| Posted: Tue Sep 12, 2006 1:00 pm Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| Michael Dag wrote: |
| PeterPotkay wrote: |
| MQClient apps do not have to supply a QM name in order to connect. |
you mean when using a client channel table? (the QMname is in the Client Channel Definition) |
...or using the MQSERVER variable. It contains channel name, IP(port) and nary a queue manager name in sight. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Sep 13, 2006 12:12 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| or using the MQSERVER variable |
Ah, now you DO have to specify the qmgr name when connecting with MQSERVER.
From the APR, MQCONN
| Quote: |
For MQ client applications, a connection is attempted for each client-connection channel definition with the specified queue-manager name, until one is successful. The queue manager, however, must have the same name as the specified name. If an all-blank name is specified, each client-connection channel with an all-blank queue-manager name is tried until one is successful; in this case there is no check against the actual name of the queue manager.
|
CLNTCONN channels are only held in the client channel table, so connecting via MQSERVER does not search for the qmgr name.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed Sep 13, 2006 5:49 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| Nigelg wrote: |
| Quote: |
| or using the MQSERVER variable |
Ah, now you DO have to specify the qmgr name when connecting with MQSERVER. |
Experience says otherwise. Running WMQ client on my Windows machine, connecting to a queue manager on UNIX I enter:
| Code: |
set MQSERVER=QM_SVRCONN/TCP/xx.xx.xx.xx(1414)
amqsputc ON.QMGR |
and I see:
| Code: |
Sample AMQSPUT0 start
target queue is ON.QMGR |
...and my messages get put to the queue.
The comments in amqsput0.c say the queue manager arg is optional, and QMName defaults to a null string if no arg[2] is supplied. So the queue manager is being opened without the name of the queue manager being specified, but rather being derived from MQSERVER setting. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Sep 13, 2006 6:45 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Interesting.
Do you have a default qmgr set up, so it connects to that?
Or, does it connect to the qmgr that is running the listener (inetd or runmqlsr) on the port?
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed Sep 13, 2006 8:25 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
No default queue manager. It connects to the qmgr associated with the port.
| Code: |
ps -ef|grep mql
mqm 3310 1 0 Aug 22 ? 0:00 runmqlsr -m QMGR -t tcp -p 1414 |
|
|
| Back to top |
|
|
|
|
