| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ communication synchronous wait |
« View previous topic :: View next topic » |
| Author |
Message
|
| GeneRK4 |
 Posted: Thu Mar 13, 2014 6:03 pm Post subject: MQ communication synchronous wait |
 |
|
Master
Joined: 08 Jul 2013
Posts: 220
|
Hi experts,
Please provide your views in my below understanding...I want to get a clear idea on the below scenarios.
1) An application is connected to a QM.When it puts the message ,it does not know the Message id,because Messageid in MQMD is generated by MQ.
When the target application sends the response for that Message,it maps the Correlation ID with the Message id .Now it sends the response back to the Source Application.
When Source application does not know the message id and as the target applciation maps Messageid for correlation,how does the Source application identify the correct response for the request?
2)If an Application wait for the response ,then it is synchronous.If it does not wait for the response,then it is asynchronous. MQ is Asychronous messaging only.And why Asynchronous is because the application need not wait for the Target application to be available at the same time.So,if we want to make it Synchronous,then the Source Application has to wait for the response message in the same thread.
Having said that,in synchronous scenario,as the same thread will be waiting for the response,and there are multiple instances placing messages into the Source queue,does the Correlation mapping by Target application required for this scenario as well?
I thought if the same thread is waiting for the response,then no need for correlation.But not sure when it is during multiple instances. |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Mar 13, 2014 10:58 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
1 - the sending application can either choose to set a known msgid - or it can see the generated one in the MQMD following the MQPUT.
2. the receiver can wait in any thread for the reply message - the reply queue can be shared - this because the reply message should be selectively retrieved using the matching feature MATCH_CORRELID (or something like that). The MQGMO_WAIT can be used to keep the MQGET active for a period (or until the message matches).
MQ is very flexible used in this request-reply mode, precisely because you don't have to wait in the same thread, or even immediately after the request.
You can do that of course, but you don't have to. It's also possible to have different reply queues for each requestor (dynamic queue) and use the reply-to-queue value in the MQMD. But this is not essential. A single request and a single reply queue can be shared.
I used to have a mainframe application with a single request queue being serviced by multiple copies of the application, and a single reply queue being used by multiple (thousands) of requestors.
This was my choice, but demonstrates how powerful MQ can be.
One thing to bear in mind when using selective retrieval is to set an expiry value in the reply messages (this can be a large value like 24 hours) just so that if the requestor fails to get the message (for any reason), it doesn't linger on the reply queue forever.
In many cases the request/reply messages can be non-persistent which gives very high performance.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 14, 2014 12:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And don't forget if you're using UOWs and transactions that the response will never be part of the same transaction as the request from the requester's point of view... The request message will have to be committed by the requester, before it can be processed by the server application sending the response.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Mar 14, 2014 1:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Also another gotcha is that to generate a different MSGID each time - you must clear the MQMD.msgid field before the next MQPUT.
Otherwise the returned MSGID value from the previous MQPUT can get re-used (depending how you initialise your MQMD between calls) and result in all your requests having the same msgid (which may or may not be a problem for you).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| 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
|
|
|
|
