Author |
Message
|
brgmo |
Posted: Mon Dec 29, 2003 11:25 am Post subject: How to match response for a particular request message |
|
|
Master
Joined: 03 Jun 2002 Posts: 227
|
Hi All
I am writing an application in which i have to recieve requests from the client as mqmessage,process that and send the response back to the client.Now, my problem here is to how to match response messages with the request message i.e. if message1 is coming from client1 and message2 coming from client2 then how to make sure that client1 should never get the response message for client2.Any java program will be really helpful.
Thanks in advance
brgmo |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Dec 29, 2003 11:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Wouldn't it be great if there were a header on each message, that would allow you to store an identification number for each request message, and then use that to correlate a reply message?
Oh, wait. There is!
The "server" should put the request Message ID into the reply Correlation ID. The client should open the ReplyToQueue and use the original message ID as a filter on the Correlation ID field to get the correct reply. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
jsware |
Posted: Tue Dec 30, 2003 12:14 am Post subject: |
|
|
 Chevalier
Joined: 17 May 2001 Posts: 455
|
More specifically, the server program should follow the flags set in the report options field. That is by default copy the incoming message id to the outgoing correlation id and give the outgoing message a new message id. If the report options say pass the message id or pass the correlation id, then do that instead (i.e. copy the incoming message/correlation id to the outgoing field).
The server application should also reply to the queue and queue manager specified in the replyto fields of the incoming MQMD. The MQPUT1 call is probably best for this (though you could cache previously opened queues and use straight MQPUT so you're not repeatedly opening the same queues).
All the client has to do is set the report options and the reply to queue (the reply to queue manager is set to the queue manager you're connected to if its left blank) and MQPUT the message.
Hope this helps. _________________ Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
Back to top |
|
 |
zpat |
Posted: Tue Dec 30, 2003 1:32 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
It's also a good idea to set the response message expiry time to a little more than the requestor is using for their GET WAIT time.
That way if the requestor has failed or gone away for any reason you won't get orphan messages on the queue (assuming that you have a way to purge expired messages which is another subject).
Most server response messages should be non-persistent for performance reasons. |
|
Back to top |
|
 |
jsware |
Posted: Tue Dec 30, 2003 12:47 pm Post subject: |
|
|
 Chevalier
Joined: 17 May 2001 Posts: 455
|
A good point from zpat.
Also on the server side, I would normally copy across the inbound expiry interval to the outbound message as the inbound expiry interval will contain the approximate amount of time left before the requester will give up.
This also works if the requester is asynchronous and has sent the request with unlimited expiry as you send back an unlimited expiry interval too. _________________ Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
Back to top |
|
 |
|