| Author |
Message
|
| hdjur |
 Posted: Mon Mar 07, 2005 8:23 am Post subject: getting reply in the preffered instance of a clustered queue |
 |
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hello!
I have this situation. I have 4 qmgrs on 4 hosts in one queue manager cluster.
QMGRA is running on host A, etc ...
Cluster queue QREQUEST is hosted by QMGRA and QMGRB.
Cluster queue QRESPONSE is hosted by QMGRC and QMGRD.
Client applications running on hosts C and D, connect to QMGRC or QMGRD (using clntconn with blank qmgr name) put messages to QREQUEST and expect to get replies synchronously from QRESPONSE instance in the same queue manager (matching correlID with request messageID).
Client applications do not care about which instance of QREQUEST
received their message, neither to which qmgr they are connected, they
just "want to stay connected" to that particular qmgr.
Server applications running on host A and B, connected to QMGRA and QMGRB respectively, get messages from QREQUEST, and have to worry about which instance of QRESPONSE will receive the message they put, otherwise, client applications would have to check for the reply in another queue manager's QRESPONSE instance, and I don't want them to connect to more than one queue manager.
Is there any way for server applications just to put message on a clustered QRESPONSE without knowing and caring from which qmgr came the request message, and that reply message ends up in the wanted destination (so that client can finish its work with just one connection)?
If not, what's the proper way to handle that situation?
In that case, is there any benefit in QRESPONSE being clustered queue?
Thanks in advance.
Bye! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Mar 07, 2005 8:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The usual way to handle this is to have the client specify both the ReplyToQueue and the ReplyToQueueManager.
Then the server app reads those from the request message, and populates the Queue Name and Queue Manager Name on the output message.
You'll have to examine your own requirements to determine how much benefit there is to have QRESPONSE clustered. How critical is the process? How tightly coupled are the clients to the QM they are connected to (for instance, are they using bindings?)? How important is load-balancing in this case, how important is the limited failover that MQ Clustering gives?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Mar 09, 2005 1:37 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hi Jeff!
Thank you for your answer. I have to define xmit queue of the name QMGRC and QMGRD on hosts A and B, channels to serve this xmit queues,
that is I will not use cluster mechanisms to put messages to QRESPONSE, QRESPONSE will be used as an ordinary, non clustered queue.
Am I right? |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Mar 09, 2005 4:09 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| No, you do not need to do that. If QRESPONSE is shared in the cluster, the reply msgs will be routed to the correct qmgr when you open the reply queue. |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Mar 09, 2005 5:23 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hi!
Thank you Nigel for your answer too. Still, my problem is that server application is developed to work with one response queue, because there was just one host C, from which client requests were coming. Now it has to be rewritten if I want to add host D. Just to add new instance of QRESPONSE in QMGRD will not do. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 09, 2005 5:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You are saying that the server application does not look at the ReplyToQ and ReplyToQmgr field in the MQMD, but always puts replies to a fixed queue with a fixed Qmgr name in the MQMD?
You can still get around this without changing the code. There are ways to use aliases to remove QMgr names in the MQMD.
But you probably should have the code changed. It should be a relatively minor change, and will make the program significantly more flexible over the long term - and reduce the amount of effort to support it over the long term.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Mar 09, 2005 6:17 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
In fact, I don't know what guys who maintain that application exactly do, they use JMS and WebSphere Application Servers, so they map their queue definitions to a queues on a local queue manager to which WAS connects, for example QMGRA, on host A. Currently, the definition to which they map their output queue is a queue alias, which points to a target queue QRESPONSE. Now, they have to add logic to read fields from MQMD, and decide where to put their reply based on this data, but first of all, they have to add new queue definition to WAS, I think they cannot access queues directly.
I'm afraid it is too complicated.
Jeff, what exactly did you have in mind when you said:
"You can still get around this without changing the code. There are ways to use aliases to remove QMgr names in the MQMD".
How to resolve my situation with this? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 09, 2005 6:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
They don't have to read the MQMD directly. The getJMSReplyTo() method on the JMSMessage object should be sufficient.
Or you could create different JNDI entries for each Queue destination, and have the programmers change the code to use the JMSReplyTo to figure out which JNDI entry to look up.
But reconsidering what I said about using aliases - you can't use aliases to make this particular decision (send to QMGR a or QMGRB). You can just use an alias to remove the Destination Queue Manager field in the MQMD - so that normal cluster resolution will occur.
So they'll have to change the code in some way.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hdjur |
| Posted: Wed Mar 09, 2005 7:36 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 09, 2005 12:44 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If the application in WAS is doing a request response scenario:
a) make sure the qcf/xaqcf has a default model queue defined
B) have the app create a temporary queue and put it into the MQMD using msg.JMSReplyTo((javax.jms.Destination) theTempQ).
This should take care of being able to return to the right qmgr.
Enjoy  |
|
| Back to top |
|
|
|
|
