>Hello All, >My understanding is that TCP guarantees the order of bytes. For all and every message and between messsages. As soon as a single >channel does not open more than one simultaneous connections between same nodes -- which it cannot do, if I am not mistaken.
>My understanding is that the "different routes" mentioned in documentation are the different paths consisting of MQSeries >channels. For example, in a cluster, you can easily end up with more than one possible path from one Queue Manager to another. >Or, you can create more than one SENDER-RECEIVER channel manually. In this case, when messages can select different channels, >FIFO will be broken. The DLQ is another possible problem (that's why I always advice against it, a opposite to the IBM's official >recommandations). >It would be nice if Paul or someone else from IBM prove or disprove that. Pavel, I think I already explained this in my previous append on this subject but let me confirm again. 1/ TCP/IP guarantees byte ordering so it doesn't matter what path the IP packets take. 2/ In the rules; when IBM talks about multiple paths it is talking about multiple MQ paths ie. multiple channels. 3/ I do agree that you can 'easily' end up with more than one path in an MQ cluster but it shouldn't happen by accident - you would have to deine multiple clusrcvrs or multiple aliases or multiple gateways. 4/ I agree the DLQ is a source for out of sequence, however, this should be a rare occurence ie. queue full Your point about DLQ is well taken but if people followed all of our advice we wouldn't be having this conversation at all. We advise that you DO NOT build a dependancy of message order into you application in the first place. It is very easy to write your code so that if you do need multiple messages in a single 'business' message that the receiving application can deal with them. Common approaches are :- 1/ Use message segmentation or grouping 2/ Use two queues - one for the primary message and one for all the secondary pieces - use something like correl id to be a sequence number so you can retrieve the messages off the secondary queue in the order you want 3/ Use a single queue but always do a GET(correlid=1) first. That message tells you whether there are correlid=2,3,4 etc etc that you should now go get. The point is not having a DLQ is generally bad for everybody. A simple application mistake could bring your channel down and therefore bring everyone down. If you have a DLQ then all other arguments are pointless - your applications should be able to deal with out of order messages. Hope this helps, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
