| Author |
Message
|
| maxis |
 Posted: Tue Oct 08, 2002 10:21 am Post subject: Interesting Question .. |
 |
|
Centurion
Joined: 25 Jun 2002
Posts: 144
|
One of customer posed this question .. for which I wasnt able to give rock solid answer. So u pl answer this question.
Programmer in US writes to QMgr A - which is in Australia. And then waits for the response message, based on correlation-Id, response queue is on QMgr B - which would be his local Queue Manager.
Once the message is received on the QMgr A, then some code will swap the Msg-Id to corrl-id and posts the message back to QMgr B.
Hope the above scenario is clear - 
Now the question - What are the possiblities of getting back response .. before I could get the message id and pass it to listener. Because message id .. would be assigned by QMgr - and the latency may take longer than the response time itself .. !
In my understanding this could happen ... anybody differ with this ?
pl post your comments .. answers .. question ...
M |
|
| Back to top |
|
 |
| kirani |
| Posted: Tue Oct 08, 2002 10:39 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
M,
If I understand ur post correctly, Msg-id will be assigned by Qmgr A on MQPUT call, you can pass the same Msg-id to your listner process, correct?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Oct 08, 2002 10:47 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
If I understand your question, you don't have a problem:
Application running against local QmgrB puts a message to a remote queue that exists on QmgrA. This will give you the message id as soon as the MQPUT returns. You could then use this id as your correlation id and issue your MQGET. The message id won't be generated by QmgrA and sent back. |
|
| Back to top |
|
|
| kirani |
| Posted: Tue Oct 08, 2002 11:13 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| bower5932 wrote: |
| The message id won't be generated by QmgrA and sent back. |
bower,
if the program makes client connection to Qmgr A then the msg-id will be generated by QmgrA. correct?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Oct 08, 2002 11:57 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
You are correct....I guess the other scenario would be:
Application makes a client connection to QmgrA. It puts a message to QmgrA's local queue and QmgrA gives it back a messageid.
The program then disconnects from QmgrA and connects to QmgrB. The program then issues an MQGET using the messageid from the put as the correlation id.
In either scenario, you're going to be ok because the put is going to give you a message id. You can then pass this message id in as the correlation id on the get. |
|
| Back to top |
|
|
| maxis |
| Posted: Tue Oct 08, 2002 4:32 pm Post subject: |
|
|
Centurion
Joined: 25 Jun 2002
Posts: 144
|
thanx bower & kiran, for such a quick response.
But unfortunatley, looks like am was not able to express the problem properly 
So allow me to try one more time ..
Application A, in US, puts the message to the Q1. Q1 is in QMgr1, which is in Australia. Application A directly puts message to the Q1 on QMgr1, no remote Queue nor Client connection. There will be a network latency, say X sec, in getting BACK the message id. Are u guys with me so far.
After putting the message, say at 10:00:00AM, application gets the message id at 10:00:00 AM + X (ie network latency). Then it passes message id to the listener.
Some process in Austalia would swap the msg-id to the corrl-id and puts back to the Response queue, which is a remote queue.
The Response Queue is residing on local queue Manager, in the same box on which App A is residing, in US. Lets say message comes to response Queue after 10:00:00AM + Y
Now the question is .. can X > Y, in other words, before I could get message Id what are the possiblities of getting back the response message ?
Since the network latency is involved, we cannt always be sure that X < Y am right ?
If still its not clear pl send Private message I'll respond ...
thanx everyone ..
M |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Oct 08, 2002 8:48 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Wow, this is an apples and oranges kind of question.
First of all, the MessageId is a unique 24-byte identifier (per queue manager). For all intensive purposes, the MessageId has nothing to do with the time value (yes, it is derived from the date/time of the local box).
The flaw to your question is in the statement:
| Quote: |
| Application A, in US, puts the message to the Q1. Q1 is in QMgr1, which is in Australia. |
If this is true then App A is a client to QMgr1 BUT then you go on to say that the response will be on a queue manager in the US.
So, the missing pieces are:What queue manager does Appl A connect to?
What is the name of the queue manager in the US?
My guess is that Appl A connects to the queue manager in the US, so lets call it QMgrA.
So, here is the picture
| Code: |
- Appl A connects to QmgrA
- Appl A puts message to QMgr1 : Q1 {1}
- QMgr1 is a XMITQ, therefore, message is transmitted to queue manager QMgr1
- MCA of QMgr1 puts message into Q1
- "Process in Australia" gets message from Q1 copies MsgId to CorrelId of response message.
- "Process in Australia" puts response message to QMgrA : REPLY.Q {2}
- QMgrA is a XMITQ, therefore, response message is transmitted to queue manager QMgrA
- MCA of QMgrA puts response message into REPLY.Q
- Appl A gets by CorrelId (using original MsgId) from REPLY.Q
- Appl A plays a little happy tune :) |
Now, {1} and {2} mark when each queue manager will generate a unique MessageId for the message being put. You only really care about {1} – I just marked {2} to be completed.
Since, Appl A is a local application connecting to a local queue manager "QMgrA in the US", the MessageId will be immediately generated and returned to Appl A {1} on the completion of the call (no latency). And not when QMgr1 receives the message.
I think your confusion centered around which queue manager was generating the MessageId.
Make sense?
Later
Roger...
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| maxis |
| Posted: Wed Oct 09, 2002 5:48 am Post subject: |
|
|
Centurion
Joined: 25 Jun 2002
Posts: 144
|
Thanx Roger...
Would be great .. if u (or anyone in this group) could tell behind scene happenings in the following scenario.
| Code: |
1. Application connects to remote Queue Manager
2. Put message
3. Get message Id
|
When the message Id would be generated. How it'll be sent back to the put application. |
|
| Back to top |
|
|
| jc_squire |
| Posted: Wed Oct 09, 2002 4:24 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
pvmk,
I am quiet confused with this one ... 
App A in US connects to QMGR in Auastralia with no remote queues or client - how is this being done ...... JAVA .....?????
Also, if APP A is getting the response message from a qmgr on the same localhost, would it not be better to send the request message to the qmgr in Australia using the local qmgr as summarised by RogerL. e.g.
US:
===
Application : AppA
Qmgr: QMA
R/Q: REQUEST.Q
L/Q: REPLY.Q
XMITQ: QMB
Australia:
======
Application: AppB
QMGR: QMB
R/Q: REPLY.Q
L/Q: REQUEST.Q
XMITQ: QMA
Procedure:
=======
- AppA connects to qmgr on localhost (QMA)
- AppA puts request message to REQUEST.Q and msg.id is returned from QMA to AppA
- QMA routes request msg to QMB
- AppA issues get specifying original msg.id as correlation id
- AppB gets request msg from REQUEST.Q, moves msg id to correlation id and puts response msg to REPLY.Q
- QMB routes response msg to QMA
Connecting AppA in US to QMGR in Australia defeats the whole point of MQSeries.
However, if you do connect AppA direct to QMGR in Aus, the latency would also affect the reply message coming back so generaly speaking you should get the msg id before you get the reply msg.
Regards
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| kolban |
| Posted: Wed Oct 09, 2002 6:56 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
I don't think it matters. There are only two possible scenarios....
Scenario 1.
Code:
MQPUT to RequestQ
MQGET from ReplyQ
In this case, the RequestQ MQPUT MUST complete before we even look for a message.
Scenario 2.
MQPUT to RequestQ
MQGET from ReplyQ
Occur in either separate threads or separate processes.
In this case, it is not even a function of MQ latency, the MQPUT call could be preempted instantly after its execution and the MQGET call executed. Heck, the MQGET call could execute at the same time as MQPUT.
I understand the question, but I fail to see a meaningful application of an answer.... |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Oct 09, 2002 10:16 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Yes, the call to MQPUT will not return (it will block) until the message is actually handed off to the queue manager and a MsgId is returned. The moment your MQPUT call returns, the MQMD structure you passed into it is populated with the MsgId that was assigned to the message. There is no network latency involved, at least between the time the MQPUT succeeds and the time you get the MsgId, because you already have it - the MQPUT returned it to you. It is not the destination queue manager that assigns the MsgId - I think this is what is confusing you. Imagine the channel between the local queue manager and the destination queue manager is down. So when you MQPUT the message, it will sit on the transmission queue in the local queue manager until the channel comes back up. Does this mean you don't get a MsgId? No.... As soon as you issue the MQPUT call, the local queue manager assigns a MsgId and returns it to you. If you browse the message as it is sitting on the transmission queue, you'll see this is the case. At no point did the local queue manager need to talk to the remote queue manager to assign the MsgId.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| maxis |
| Posted: Thu Oct 10, 2002 7:27 am Post subject: |
|
|
Centurion
Joined: 25 Jun 2002
Posts: 144
|
J C Squire,
Yes, you are right I had java app in my mind for this scenario.
| Quote: |
However, if you do connect AppA direct to QMGR in Aus, the latency would also affect the reply message coming back so generaly speaking you should get the msg id before you get the reply msg. |
Even I agree with what you are saying .... my question ulitimately boils down to this. Will this assumption holds good, always ?
thanx everyone .. for your answer and time ...
I really appreciate it ...
M |
|
| Back to top |
|
|
| bigdavem |
| Posted: Thu Oct 10, 2002 10:19 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia
|
| I understand what you're asking, but I don't understand why it matters if the message arrives on the reply queue in the US before the MsgId is returned? Unless the reply is triggering a process which will need to know the MsgId? But even then the triggered process could just have logic in it to wait if the MsgId isn't available yet.... |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Oct 10, 2002 11:44 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I dug around in the MQSeries manuals to see if I could answer your "Will this assumption holds good, always ?" with a simple yes or no. Unfortunately there isn't anything compelling. What seems to leave the question open ended is this statement from the Application Programming Reference:
| Quote: |
| If there is a possibility that some messages in the sequence may go on a different path (for example, because of reconfiguration, traffic balancing, or path selection based on message size), the order of the messages at the destination queue manager cannot be guaranteed. |
If the order of the messages themselves aren't guaranteed, then it seems to indicate that there is no guarantee of your application getting its response back from the MQPUT call before the reply message is delivered to the reply queue - especially when we are talking about environments with very high network latency and lots of routers in between. But as bigdavem asked, why does this matter? It would seem that unless your reply messages have a very short expiry time, it shouldn't hurt if they arrive before the requesting application has issued an MQGET to retrieve them.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| maxis |
| Posted: Tue Oct 15, 2002 8:50 am Post subject: |
|
|
Centurion
Joined: 25 Jun 2002
Posts: 144
|
thanks a lot to everyone  ... in particular to Brandon you've shown the responsibility of a MODERATOR ... 
M |
|
| Back to top |
|
|
|
|
