| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| A question about FIFO of the queues. |
« View previous topic :: View next topic » |
| Author |
Message
|
| thomas2004 |
 Posted: Fri Nov 14, 2008 5:19 am Post subject: A question about FIFO of the queues. |
 |
|
Novice
Joined: 13 Nov 2008
Posts: 16
|
I read from the document that the queues work in a principal of FIFO (First In First Out). That means, if the first mesaage is not taken away jet, the second one can not be catched.
I make a test and it seems it is not so. I did as follow:
I wrote test program A and B.
Program A to send a message to the Request-Queue. The MQ-manager will generate an ID on it. Then program A will wait for the reponse from program B
Program B holds out the message sent from A and attachs some test to it and set another Id on it and send it back to A.
Since A just wait for message sent back from B with the same message Id, it get nothing from the Response-Queue.
This means, a message is stocked in the Response-Queue. I can confirm this by checking the currentDepth of the Response-Queue. Let's call this message as 'wrong message'.
Now I let A send a message again and wait for the response.
And I change B and let B holds out this message from the Request-Queue and attach some test to it. This time I don't add a new message Id on it but at the same id (respMessage.correlationId = inMsg.messageId;) and send it back to Response_Queue.
This time the A can receive the response and goes end.
But the 'wrong message' is still stocked in the Response-Queue.
Who can explain? |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Nov 14, 2008 5:53 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
queues can be processed fifo or by message priority. in both cases, it is still possible to get a message with specific "keys", e.g. messaage id and correlid.
to me, your test program A is in error, because it does not look to me that you really wanted that kind of processing you get by intention.
program a puts a message, gets a msgid from this put and then expects a reply with the same msgid (because you coded it this way or because you missed to reset the msgid before the mqget).
this it the reason why msg 1 with a different msgid is not read from the queue, but msg2 is, because it is the same msgid. if you code your program properly it weill also get msg1.
if you really like to set up a request - reply application, then there is something like a "standard request - reply " - behaviour for application, or best practise, however you would like to call it.
the msgid of the request msg is copied to the corelid of the reply msg, thats what lots of people use on this kind of application
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 14, 2008 6:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mr Butcher wrote: |
queues can be processed fifo or by message priority. in both cases, it is still possible to get a message with specific "keys", e.g. messaage id and correlid.
to me, your test program A is in error, because it does not look to me that you really wanted that kind of processing you get by intention.
program a puts a message, gets a msgid from this put and then expects a reply with the same msgid (because you coded it this way or because you missed to reset the msgid before the mqget).
this it the reason why msg 1 with a different msgid is not read from the queue, but msg2 is, because it is the same msgid. if you code your program properly it weill also get msg1.
if you really like to set up a request - reply application, then there is something like a "standard request - reply " - behaviour for application, or best practise, however you would like to call it.
the msgid of the request msg is copied to the corelid of the reply msg, thats what lots of people use on this kind of application |
Another method is to have the requesting application create a dynamic temporary queue and supply that name in the message. The responding app then puts the reply to that queue; because the queue is only known to that request, any message on it must be the reply irrespective of msg id.
The pros & cons of these 2 methods have been discussed many times on the forum.
Happy Reading! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
