| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Messages transmitted in wrong order to remote qmgr |
« View previous topic :: View next topic » |
| Author |
Message
|
| broderd |
 Posted: Wed Feb 07, 2007 12:49 am Post subject: Messages transmitted in wrong order to remote qmgr |
 |
|
Newbie
Joined: 07 Feb 2007
Posts: 2
|
Hi guys,
This is my first post for an unusual problem.
We have an OS/390 qmgr in London connected to a Unix qmgr in Germany. My CICS application is putting two messages within a unit of work, using a common DB2 stored procedure to interface with MQ. These messages must be received in the order I put them for the receiving application to work ok.
The problem is, they appear on the remote queue in the wrong order.
Queues are defined FIFO and we have checked the PUTDATETIME on the message headers, and these correctly show that I put them in the correct order, but they have been retrieved in the wrong order.
The end-end process is single threaded - 1 putting application, one channel, one getting application, no clustering.
We have also done a test where the channel has been stopped when the messages were put - in this case, the messages appeared in the correct order! I have also tested putting to a local queue, and this works fine too - messages are in the correct order.
Any ideas on what we're doing wrong?
Thanks,
Danny. |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Feb 07, 2007 12:55 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I don't believe MQ guarentees that messages will arrive in the sequence they were sent.
You can use "groupid" messages and look at parameters such as MQGMO_LOGICAL_ORDER and/or MQMO_MATCH_MSG_SEQ_NUMBER
Check out the App Prog Ref manual.
| Quote: |
Applications that simply want to retrieve messages and segments in logical
order are recommended to specify MQGMO_LOGICAL_ORDER, as this is
the simplest option to use. This option relieves the application of the need
to manage the group and segment information, because the queue manager
manages that information. However, specialized applications may need
more control than provided by the MQGMO_LOGICAL_ORDER option,
and this can be achieved by not specifying that option. If this is done, the
application must ensure that the MsgId, CorrelId, GroupId, MsgSeqNumber,
and Offset fields in MQMD, and the MQMO_* options in MatchOptions in
MQGMO, are set correctly, prior to each MQGET call.
If MQPMO_LOGICAL_ORDER is specified, the queue manager automatically
generates a unique group identifier for the first message in the group or segment
of the logical message, and uses that group identifier for the remaining messages
in the group or segments of the logical message, so the application does not
need to take any special action. This is the recommended procedure. |
|
|
| Back to top |
|
|
| broderd |
| Posted: Wed Feb 07, 2007 1:09 am Post subject: |
|
|
Newbie
Joined: 07 Feb 2007
Posts: 2
|
Yes, I didn't think MQ guaranteed the order either. It's just the first time I've seen the order coming out differently.
I have also been reading about Sequence numbers used by channels to keep the messages in order (Intercommunication), which suggest that if the messages are on the xmit queue in the correct order, then they should arrive in the same order.
If I am reading it correctly, then it appears the order is getting messed up on one of the qmgrs before getting to the xmitq (or after arriving at the remote xmitq), rather than over the network.
Anyway, I will look into the logical grouping options, and hopefully this will fix the issue.
Thanks for your help.
Danny. |
|
| Back to top |
|
|
| Ivans |
| Posted: Wed Feb 07, 2007 5:10 am Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006
Posts: 48
Location: Hursley
|
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Wed Feb 07, 2007 8:15 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
| As someone posted, the doc clearly states the criteria for sending messages in sequence sent. I'm fairly sure you can rule out TCP/IP sending packets out of sequence - if that did happen, the error would be handled at the TCP/IP level, not MQ. I would have to believe that the problem is within the MQ message flow, e.g. DLQ retry/requeuing, swapping XMITQs between messages, or something along those lines. Then, there's always the possibility of an MQ bug. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 07, 2007 12:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20700
Location: LI,NY
|
| rtsujimoto wrote: |
| As someone posted, the doc clearly states the criteria for sending messages in sequence sent. I'm fairly sure you can rule out TCP/IP sending packets out of sequence - if that did happen, the error would be handled at the TCP/IP level, not MQ. I would have to believe that the problem is within the MQ message flow, e.g. DLQ retry/requeuing, swapping XMITQs between messages, or something along those lines. Then, there's always the possibility of an MQ bug. |
Has anybody thought of different network paths?
You send message A and message B out over the network. For whatever different reasons message A takes path A and message B takes path B.
All paths not being equal the time it takes to travel on path A is > 500ms longer than the time it takes to travel path B. (more routers, collisions etc...)...
So you end up with message B on the queue before message A.
Nothing to do with MQ ... All TCP/IP and WAN
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 07, 2007 12:39 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That would require that the channel quiesced between messages, I think.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 07, 2007 12:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20700
Location: LI,NY
|
| jefflowrey wrote: |
| That would require that the channel quiesced between messages, I think. |
I beg to differ. That would just require the network to have enough time between messages to choose to opt for a faster route... and could well happen outside of MQ.
Each of the routers between source and target is making some decision as to how to move messages to the next hop for the given destination. This decision is usually made depending on known network algorithms...
As soon as messages travel over the WAN there is no guarantee as to when they arrive, nor which network path they will take.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 07, 2007 1:06 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So what's the receiving MCA going to do when it sees packets for message #2 (in the channel batch), when it's waiting for packets for message #1 (in the channel batch)?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 07, 2007 1:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20700
Location: LI,NY
|
| jefflowrey wrote: |
| So what's the receiving MCA going to do when it sees packets for message #2 (in the channel batch), when it's waiting for packets for message #1 (in the channel batch)? |
I was thinking more of having possibly 2 messages within the same batch arrive at different speeds...
Once the batch is complete...
The other scenario would cover 2 batches.
Both batches report success to the sending qmgr.
Batch 2 might report before batch 1?? Would that give us a channel in doubt ??
We are not talking about hours but miliseconds here. In any case the interval would fit between 2 heart beats...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Thu Feb 08, 2007 8:18 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
| If you do not affect the channel path from MQ's perspective, e.g. send a message, stop the channel, reassign the xmitq to another channel taking an alternative path, start the channel, send another message, then the messages should be presented to the receiving application in their logical sequence. In this case, we are assuming we have not violated any of the other criteria established for sending messages in sequential order. In addition, MQ uses a sequence number that the sender and receiver use to ensure synchronization. If the receiver gets a value other than what's expected, MQ issues an error message and goes into retry. |
|
| 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
|
|
|
|
