Author |
Message
|
nethaji |
Posted: Tue May 21, 2002 12:32 pm Post subject: Network change will affect? |
|
|
 Apprentice
Joined: 23 Jul 2001 Posts: 26 Location: Virginia
|
Hi ,
We have a Mq series application running a Point to Point file transfer. The application uses the FIFO (First in First out) method and it is running good so far. Now that we have another client who is going to send a file in some other pattern (round-robin like). My confusion is that, will the message arrive in the same manner (FIFO) as it has been sent even though if it takes the longest possible way in its route. (Let us assume the priority is same for all the message).?
regards
Subash |
|
Back to top |
|
 |
RogerLacroix |
Posted: Tue May 21, 2002 8:31 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
MQSeries does NOT guarantee message sequencing between 2 queue managers. It is very rare but yes, if you send messages 1,2,3 & 4 between 2 queue managers, you may receive the messages as 1,4,2, & 3 at the other end.
Therefore, you should be using Message Grouping.
later
Roger… |
|
Back to top |
|
 |
kirani |
Posted: Tue May 21, 2002 8:45 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
Roger,
Just curious to know under what circumstances the messages will not come in sequence? What if there is only one channel defined between these two queue managers?
Regards,
Kiran _________________ 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 |
|
 |
RogerLacroix |
Posted: Tue May 21, 2002 8:56 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Hi,
Yes it can happen even with one channel. Generally the situation relates to things done under the covers. e.g. TCP routing problems, how the MCA is handling the message de-construction / construction, plus I think IBM makes the states in one of the manuals (Intercommunication?).
Since '94, I have only ever seen it happen a handful of times. But I would not bet my job on it never happening again.
Basically, this was one of the major reasons why IBM introduced MQSeries Message Grouping.
later
Roger... |
|
Back to top |
|
 |
mqonnet |
Posted: Wed May 22, 2002 4:29 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Roger, not quite sure if i am 100% right. But if you have a point to point architecture and you have only one Channel Defined between 2 QM's, the messages WILL reach the other QM in the order in which they were sent from the 1st QM. All this, only if you have one application sending the messages.
But yes, if you have more than one application sending messages from QM1 to QM2 using the same channel, then the messages order CANNOT be guaranteed.
Any comments appreciated.
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
mrlinux |
Posted: Wed May 22, 2002 4:45 am Post subject: |
|
|
 Grand Master
Joined: 14 Feb 2002 Posts: 1261 Location: Detroit,MI USA
|
The nature TCP/IP and underlying hardware, there is no way you can assume a message will arrive in order
example if you have multiple routes from one box to another then it is possible that one message may take a different route. Also how about the
issue if a router fails on message number 2 (router is powered off) the message will be retransmitted but only after message 3 and 4 are deleivered. _________________ Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
mqonnet |
Posted: Wed May 22, 2002 5:16 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Right jeff.
But under normal conditions and that is what we consider as basis/benchmar, i would think that the message WILL arrive in order.
QM1->QM2. There is only one channel defined. Only one remote and local queues respectively on both the Qms. There is only one app putting messages in order. The messages WILL ALWAYS arrive in order.
Since i am dealing only with basics here and what should happen, let us leave aside instances of pulling the plug and tcp/ip failures for discussioni sake.
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
mrlinux |
Posted: Wed May 22, 2002 7:46 am Post subject: |
|
|
 Grand Master
Joined: 14 Feb 2002 Posts: 1261 Location: Detroit,MI USA
|
The issue has nothing to do with MQSeries, TCP/IP cannont guarntee message order from one system to another, Since MQSeries use TCP/IP
there is no way for MQSeries to do it either. _________________ Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed May 22, 2002 8:37 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Don't the MCAs on both sides confirm delivery of message #1 before sending Message #2?
Once a message has made it into an XMIT queue, I would assume it would make it to the other side in the same relation to messages ahead or behind of it in the XMIT queue, i.e. messages arrive in order.
Now, some ways to screw this up are to put some of the messages in the batch in syncpoint and other outside syncpoint (then non-syncpoint messages would be available on the other side before the syncpointed ones if the BatchInterval has not been reached). Arriving in order and being available in order are 2 seperate things.
Or, Put messages to the remote queue, but message 1000 fills up the XMIT queue. Message 1001 ends up in the DLQ. Temporary problem causing the XMIT queue to fill up ends, so messages 1002 and up go to the other side. In the meantime your DLQ handler reputs the message to the queue and now 1001 arrives after 1002.
I spoke with the Hursley guys at the Dallas Conferance about this exact thing (TCP packets arriving out of order) and they said this does not affect message ARRIVING order. If message A makes it to the XMIT queu before message B, it will arrive on the other side before B, assuming all the messages in this group are similiar (persistence and syncpoint-wise).
I am going from memory here, so if I am not 100% correct, please let me know. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mrlinux |
Posted: Wed May 22, 2002 8:59 am Post subject: |
|
|
 Grand Master
Joined: 14 Feb 2002 Posts: 1261 Location: Detroit,MI USA
|
I remember this question from Dallas, and from my MEMORY(subject to be incorrect)
If you set the batch size to one then it would confirm one message at a time that would guarntee them getting there in order. _________________ Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
DRoberts |
Posted: Wed May 22, 2002 9:51 am Post subject: |
|
|
 Novice
Joined: 30 Apr 2002 Posts: 14
|
In the MQSeries Application Programming Reference, Chapter 35 MQPUT Usage Notes section states:
Quote: |
2 If an application puts a sequence of messages on the same queue without using message groups, the order of those messages is preserved provided that the conditions detailed below are satisfied. Some conditions apply to both local and remote destination queues; other conditions apply only to remote destination queues.
|
I will not list all the conditions because it is quite lengthy, but it is worth the look. _________________ Deborah Roberts
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
mrlinux |
Posted: Wed May 22, 2002 10:02 am Post subject: |
|
|
 Grand Master
Joined: 14 Feb 2002 Posts: 1261 Location: Detroit,MI USA
|
Well the Chapter 35 basicaly states that
There is only one path from the sending queue manager to the destination queue manager. (Since they dont spell it out I believe they mean TCP/IP path)
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. _________________ Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
DRoberts |
Posted: Wed May 22, 2002 10:12 am Post subject: |
|
|
 Novice
Joined: 30 Apr 2002 Posts: 14
|
Jeff ,
Right, I agree with you. The manual is giving the specific conditions that it will preserve message order. Any other condition (ie messages taking different paths) - no guarantee.
Deb _________________ Deborah Roberts
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
nethaji |
Posted: Wed May 22, 2002 11:02 am Post subject: |
|
|
 Apprentice
Joined: 23 Jul 2001 Posts: 26 Location: Virginia
|
Hi all
Thanks for all the information. I came to know that order of the message is not garunteed in the MQ. I am using MQ 5.2 in s/390 system. If I am not wrong, it does not support messgae grouping or message segmentation (see the quote from APP programming guide Chap10). so the only way to handle this issue is through application design. Any other idea?
Quote: |
Logical and physical ordering
Logical and physical ordering is supported on MQSeries Version 5 products only, except
MQSeries for OS/390. |
|
|
Back to top |
|
 |
mrlinux |
Posted: Wed May 22, 2002 11:56 am Post subject: |
|
|
 Grand Master
Joined: 14 Feb 2002 Posts: 1261 Location: Detroit,MI USA
|
Well If you (meaning place of employment) can be patient and can get MQ V5.3 installed (due Oct 2002) it supports message groups, if my memory from Dallas serves me right. _________________ Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
|