Hello Dennis:

With all my respect, I cannot buy the analogy: SQL standard does not guarantee any 
specific order of the rows in the "select" result unless you use "order by" clause, 
but MQSeries documentation does...

WRT using grouping, correlation ids and other similar techniques for getting messages 
in order, they are often too expensive wrt execution time and CPU cycles (especially 
on platforms other than mainframe where you cannot index the datafile AFAIK) and, by 
the very variety of the techniques used to solve this simply stated task, you can say, 
no one of them is ideal and generic enough :-).

Thank you,
Pavel




                      "Miller, Dennis"
                      <[EMAIL PROTECTED]        To:       [EMAIL PROTECTED]
                      OM>                      cc:
                      Sent by: MQSeries        Subject:  Re: messages out of order
                      List
                      <[EMAIL PROTECTED]
                      n.AC.AT>


                      02/24/2003 11:50
                      AM
                      Please respond to
                      MQSeries List






>I disagree that out-of-box MQ message order guarantees are unusable: all limitations, 
>explicitly spelled in the documentation sound
>quite reasonable to me and, for many (ok, some :-) ) applications, they can be obeyed 
>without any harm.

Reminds me of a database programmer who cursors through a select without the "order 
by" clause. The application passes all tests and runs fine for a long time. Then 
someday, for some reason, the rows come back in the wrong order and nobody knows why. 
Or worse, something gets screwed up and goes unnoticed.  Maybe somebody tweaked a 
tuning parameter or some tablespaces were moved to a different disk drive.  Lizette's 
experience is not all that uncommon and demonstrates exactly why MQ applications 
should not rely on message order if it is important to the application.

I respect managers that take the extra effort to use best practices in the first 
place. The additional effort to design the application for assuring message order is 
trivial. If it's important to the business, then do it. The cost of figuring out what 
wrong and fixing the damage likely outweighs the cost of a better design.

> -----Original Message-----
> From: Pavel Tolkachev [SMTP:[EMAIL PROTECTED]
> Sent: Saturday, February 22, 2003 4:36 PM
> To:   [EMAIL PROTECTED]
> Subject:           Re: messages out of order
>
> I am not trying to defend that design (many on the list know I personally think the 
> very dlq existence is sort of bad design or, ok, 'quick, dirty and incomplete way to 
> specify the app's data transmission error processing policies' -- please do not beat 
> me for this again :-) ). Still I think that the original question of Lizette's 
> managers and/or programmers is quite legitimate: why in this particular case the 
> application gets messages out of order? Personally I respect managers who do not buy 
> the general explanations of type: "the application is poorly designed" until and 
> unless they are given the concrete scenario for their particular situation that 
> cannot be disproved at very least (ideally, it should be proved to be the case).
>
> I disagree that out-of-box MQ message order guarantees are unusable: all 
> limitations, explicitly spelled in the documentation sound quite reasonable to me 
> and, for many (ok, some :-) ) applications, they can be obeyed without any harm. I 
> am not sure, however, how the intermittent problems with the queue should be 
> processed if the queue itself is a dlq -- it would be interesting to hear from IBM 
> or someone who knows. Also, could anyone trace the Dave's guess about resource 
> locking as a possible reason for out-of-sequence messages down to the documentation?
>
> Thank you,
> Pavel
>
>
>
>
>
>
> See that's what I like about management. They complain about paying too much
> for their technical people. Are constantly trying to hire cheap labor and
> when they are slapped in the face with facts they completely ignore anybody
> around them with a clue as to what is going on and make a decision in a
> vacuum!!! Wonderful. I guess IBM should hire your managers to set policy
> from now on because THEY ARE OBVIOUSLY RIGHT!!
>
>                              hahahahahaha
>                                   bobbee
>
> PS All hands abandon ship!!!!
>
>
>
>
>
>
>
> >From: Glen Larson <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: messages out of order
> >Date: Fri, 14 Feb 2003 14:15:15 -0600
> >
> ... <skipped>
> >sounds like the pointy hair boss,  clueless decisions based on the premise
> >of: "thats the way we've always done it."
> ... <skipped>
> > > > > > > > -----Original Message-----
> > > > > > > > From: Hill, Dave [mailto:[EMAIL PROTECTED]
> > > > > > > > Sent: Tuesday, February 11, 2003 1:19 PM
> > > > > > > > To: [EMAIL PROTECTED]
> > > > > > > > Subject: Re: messages out of order>
> > > > > > > >
> > > > > > > >
> > > > > > > > You could be getting data locks  ( resource
> > > > > > > locking ) that is not allowing
> > > > > > > > certain records from being "extracted" in order.
> > > > > > > We had a problem like
> > > > > > > this
> > > > > > > > and it was a timing problem in a database.
> > > > > > > > One question:
> > > > > > > > What is the dead letter queues process?
> ... <skipped>
> > > > > > > >
> > > > > > > > >  -----Original Message-----
> > > > > > > > > From:         Anderson, Lizette T. (RyTull)
> > > > > > > > > Sent: Tuesday, February 11, 2003 1:04 PM
> > > > > > > > > To:   [EMAIL PROTECTED]
> > > > > > > > > Subject:      messages out of order
> > > > > > > > >
> > > > > > > > > Is it possible for messages to be delivered out
> > > > > > > of order?  Please read
> > > > > > > the
> > > > > > > > > following from our application programmer:
> > > > > > > > >
> > > > > > > > > We had a problem last night.  A couple of our MQ
> > > > > > > message were processed
> > > > > > > > > out of order.  The MQ messages are for Score
> > > > > > > Order Entry feedback from
> > > > > > > the
> > > > > > > > > mainframe.  The queue name is
> > > > > > > RT.PRD.ORDFBREC.INB.  The sequence of
> > > > > > > > > process the messages take to reach the queue
> > > > > > > are:
> > > > > > > > > -The mainframe writes records to an Adabase file
> > > > > > > storing MQ information,
> > > > > > > a
> > > > > > > > > Natural program performs this process.
> > > > > > > > > -The mainframe then reads records from this
> > > > > > > Adabase file and generates
> > > > > > > MQ
> > > > > > > > > messages, a Cobol program performs this process.
> > > > > > > > > -The MQ messages are delivered to the dead
> > > > > > > letter queue.>
> > > > > > > > > -The message are extracted from the dead letter
> > > > > > > queue and delivered to
> > > > > > > the
> > > > > > > > > RT.PRD.ORDFBREC.INB queue.
> > > > > > > > > -A C program process the records from this
> > > > > > > queue.
> > > > > > > > >
> > > > > > > > > From looking at the debug log we know the MQ
> > > > > > > messages were process out
> > > > > > > of
> > > > > > > > > sequence.  The only way they could be processed
> > > > > > > out of sequence is if
> > > > > > > they
> > > > > > > > > were added to the RT.PRD.ORDFBREC.INB queue in
> > > > > > > the wrong order.  The
> > > > > > > > > mainframe process and records in the Adabase
> > > > > > > file look to be in order.
> > > > > > > > > So, the records should have been added to the
> > > > > > > dead letter queue
> > > > > > > correctly.
> > > > > > > > >
>
>
>
>
>
>
> --
>
> This e-mail may contain confidential and/or privileged information. If you are not 
> the intended recipient (or have received this e-mail in error) please notify the 
> sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
> distribution of the material in this e-mail is strictly forbidden.
>
> 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

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





--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.

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

Reply via email to