ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » News/Updates » WebSphere MQ V5.3 Annonuced today

Post new topic  Reply to topic Goto page Previous  1, 2
 WebSphere MQ V5.3 Annonuced today « View previous topic :: View next topic » 
Author Message
RogerLacroix
PostPosted: Wed Jul 03, 2002 8:18 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada

It is hard too do but given the right MQ environment and a little patience, I can get Msg#2 to be delivered before Msg#1.

The more hoping of messages thru queue managers, there easier it is to reproduce.

e.g. QM1 -> QM2 -> QM3
No direct connection between QM1 and QM3.

Now at a network level, if between QM1 and QM2 you have at least 2 routers (preferably more), 1 of which is very slow, the odds increase that the Msg#2 will be delivered before Msg#1.

And if between QM2 and QM3 you have at least 2 routers (preferably more), 1 of which is very slow, the odds greatly increase that Msg#2 will be delivered before Msg#1.

Now pound / launch 100,000 messages within a hour (or shorter) time frame and usually I can say bingo in the first few tries (Msg#"n+1" passes Msg#"n").

As you can see, it is not easy to do, but it can happen.

later
Roger Lacroix
Enterprise Architect
Capitalware Inc.
http://www.capitalware.biz
----------------------------------------
IBM Certified Specialist - MQSeries
IBM Certified Developer - MQSeries
IBM Certified Solutions Expert - MQSeries
----------------------------------------
Back to top
View user's profile Send private message Visit poster's website
nimconsult
PostPosted: Wed Jul 03, 2002 9:53 pm    Post subject: Reply with quote

Master

Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium

RogerLacroix wrote:
It is hard too do but given the right MQ environment and a little patience, I can get Msg#2 to be delivered before Msg#1.


This is extremely important information, Roger.

I know critical (financial) applications running in a production environment that rely on the fact that the message sequence is not broken.

My questions are:
- Do you mean that you have actually performed this test and saw messages in the wrong order??? I mean is this just speculation or real facts?
- Does this mean that the message sequence number maintained by MQ Series is not as informative as one might expect? If I see current message sequence number is 2, it does not necesseraly mean that the message with sequence number 1 has arrived?
- How does MQ Series maintain this information? How then is MQ Series able to resynchronize channels in case of restart, and assure once-only delivery?
- If this is true the MQ Series documentation (and the recommendation of MQ Series specialists) contains a critical mistake and should be corrected.

Thank you in advance for your reply, I really need to know more about this.
_________________
Nicolas Maréchal
Senior Architect - Partner

NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be
Back to top
View user's profile Send private message Send e-mail Visit poster's website
kolban
PostPosted: Thu Jul 04, 2002 5:21 pm    Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

I won't say this is wrong but thinking about how MQ works I don't see how it would be possible.

A channel is a single TCP/IP connection. To send a message from one queue manager to another, the message is staged on the XMIT queue and then a SINGLE thread grabs the message from the queue and sends it down the socket. When the whole message has been sent then the next message is sent.

At the receiving end, the messages are received by a single thread that builds the message from the incoming stream and puts them to the target queues.

If there are multiple network paths between A and B, then that is saying that multiple IP datagrams could take different routes ... that's fine. But the TCP layer guarantees that data put into one end of a socket pipe is received at the other end in EXACTLY the order submitted.

From this, I don't see how an underlying IP datagram route can possible cause multiple messages to be re-ordered.
Back to top
View user's profile Send private message
kirani
PostPosted: Thu Jul 04, 2002 6:58 pm    Post subject: Reply with quote

Jedi Knight

Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA

Has anyone seen this (messages out of order) happening in real world? If this is true then we are in a BIG trouble! We are planning on exchanging 7-10 million messages daily between Mainframe and Win2K queue managers.

_________________
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
View user's profile Send private message Visit poster's website
RogerLacroix
PostPosted: Sun Jul 07, 2002 9:03 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada

All:

Yes, I have "seen" it happen. The first time was in the mid-90's when I was doing some monstrous stress testing for a MQ middleware / middle-tier application for a large Canadian bank.

I remember the first time very well, because I had "prove" it to my manager. I had to request an extra month of project time to write a data handler routine (because we could not live with 99.99% of the time concept - it had to be 100%). The manager then called in the IBM reps and I had to prove it to them. Sometime later I was told by one of the IBM reps that the problem / requirement (by other companies too) had lead to the Message Grouping with Logical Ordering option in version 5 (or was it 5.1 ?? can't remember - think it was v5) of MQSeries.

Note: We are referring to messages not remaining in the "PUT" order between queue managers.

Also, there seems to be some confusion about the channel sequence number. This is NOT a message number. From an application developer's perspective, you should never care about the channel sequence number. The channel sequence number is ONLY for the MCA's use. And a message will probably be made up of many channel sequence numbers as the MCA sends the message across the channel (and yes, it is used as part of the "once and only once" delivery philosophy).

Note: The documentation states that "PUT" order is guaranteed within a queue manager. It does NOT make this claim between queue managers.

later
Roger...
Back to top
View user's profile Send private message Visit poster's website
nimconsult
PostPosted: Sun Jul 07, 2002 10:14 pm    Post subject: Reply with quote

Master

Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium

Not true for the documentation, Roger (with all your respect of course). The documentation states that the order of messages is maintained between different queue managers. Read the "MQ Series Intercommunication" manual, Part 2 (How intercommunication works), chapter 4 (MQ Series distributed messaging techniques), section "Channel message sequence numbering":

Quote:
The channel uses sequence numbers to assure that messages are delivered, delivered without duplication, and stored in the same order as they were taken from the transmission queue.


The next sub-section "Sequential retrieval of messages" explains the conditions required to keep the order of messages. No statement on TCP/IP routers at all. (read my previous post for a summary of the conditions).

I still cannot imagine how messages could be mixed (I have never been able to produce such an event even in large stress tests - but it's true that it was not the purpose of our tests).

Although a channel is a one-way link between queue managers, the underlying TCP/IP communication between the pair of MCAs is bi-directional. The sender MCA sends messages within batches (of max 50 messages by default). At the end of a batch the receiver MCA sends a confirmation to the sender, before the transmission of the next batch (that's where they synchronize the unit of work). This is a pure sequential process, you never have more than one "pending batch" at a time. Inside one batch of messages, you have no mix of messages on the network, because it is the role of the TCP/IP layer to ensure that the IP datagrams are received in the order in which they were sent.

Can someone tell me where I'm wrong? Roger, do you have a clue?

Thank you
_________________
Nicolas Maréchal
Senior Architect - Partner

NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » News/Updates » WebSphere MQ V5.3 Annonuced today
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.