Robert,
I forgot to mention I meant internal MQSeries locks implementing the transactional
operations, not browsing with MQGMO_LOCK option. If your browsing application use the
latter, there is no surprise that App2 cannot see the message, but why would it be
used if you just wanted to check if the message is on the queue?
Pavel
---------------------- Forwarded by Pavel Tolkachev on 05/30/2002 06:15 PM
---------------------------
From: Pavel Tolkachev on 05/30/2002 06:11 PM
To: MQSeries List <[EMAIL PROTECTED]>
cc:
Subject: Re: Problem receiving messages from a restarted client applicatio n.
(Document link: Pavel Tolkachev)
Robert,
First of all, according to the MQGMO_SYNCPOINT docs, you cannot use MQGMO_SYNCPOINT
and BROWSE_.. at the same MQGET.
So browse as it is always running out of UOW should (again IMHO!) see the message
without problems until it is deleted with MQCMIT after another (destructive)
transactional MQGET or with non-transactional destructive MQGET. All other
transactional operations (puts, gets) should block as soon as they try to use locked
object (I am not sure if MQ locks UOW resources on message or queue level, my guess it
is "message") until locking UOW is finished.
Pavel
---------------------------------------- Message History
----------------------------------------
From: Robert Broderick <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 05/30/2002
03:31 PM AST
Please respond to MQSeries List <[EMAIL PROTECTED]>
DELEGATED - Sent by: MQSeries [EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Problem receiving messages from a restarted client applicatio
n.
What if you do a browse with a lock and then do a get-msg-under-cursor???
>From: Pavel Tolkachev <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Problem receiving messages from a restarted client applicatio
> n.
>Date: Thu, 30 May 2002 14:06:52 -0400
>
>Andy:
>
>But don't you lock the queue at the moment you start reading the message
>while you still do not know the length and whether the message would be
>truncated or not? Even for MQGET which is in UOW?
>
>That would mean that you first check the length and only then lock the
>queue. If so, what if some other application (say, non-transactionally)
>steals the message before the transactional one can get it? Then you might
>have inconsistent information (the length from the 1st message while
>getting the 2nd one)? I do not understand how it works then. Or do you
>perform the double check?
>
>Sorry for asking about the internals but so far I beleived I understood how
>it works.. now I don't. :-(
>
>Thank you,
>Pavel
>
>---------------------------------------- Message History
>----------------------------------------
>
>
>From: Andrew Hickson <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on
>05/30/2002 06:26 PM CET
>
>Please respond to MQSeries List <[EMAIL PROTECTED]>
>
>DELEGATED - Sent by: MQSeries [EMAIL PROTECTED]>
>
>
>To: [EMAIL PROTECTED]
>cc:
>Subject: Re: Problem receiving messages from a restarted client
>applicatio n.
>
>
>Dennis,
>Truncated msg failed doesn't change the queue state and so there's no
>backout action for this hConn (typically the UOW won't even have been
>created). As there's no backout action we don't consider waking up another
>MQGET when we discover that the first client ends.
>
>rgds
>Andy.
>
>"Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002
>06:02:56 PM
>
>Please respond to MQSeries List <[EMAIL PROTECTED]>
>
>Sent by: MQSeries List <[EMAIL PROTECTED]>
>
>
>To: [EMAIL PROTECTED]
>cc:
>Subject: Re: Problem receiving messages from a restarted client
> applicatio n.
>
>
>
>Thank you for the clarification. In doing more reading last night, I came
>to
>the same conclusion, but it's always nice to get confirmation from the
>source.
>
>Quite annoyingly, I believe it's MQCC_WARNING/MQRC_TRUNCATED_MSG_FAILED,
>which may add to the confusion.
>
>I understand the scenario to be that this sequence, with an adequate buffer
>size, works as expected:
>
>App1 agent issues MQGET+wait+syncpoint
>App2 agent issues MQGET+wait+syncpoint
>App1 client crashes
>Message arrives
>Message is delivered to App1 agent with RC=0
>MQ discovers that client is gone
>App1 agent disconnects and rolls back message
>Message is delivered to App2 agent with RC=0
>
>
>However, when the buffer is too small, the following is observed:
>
>App1 agent issues MQGET+wait+syncpoint
>App2 agent issues MQGET+wait+syncpoint
>App1 client crashes
>Message arrives
>Message is not delivered to App1 agent because RC=2080
>MQ discovers that client is gone
>App1 agent disconnects and rolls back (exactly what, if anything, get's
>rolled back is interesting)
>App2 agent does not see message <==========why is this???????????
>App3 agent issues MQGET+wait+syncpoint
>App3 agent's MQGET returns with RC=2080
>
>
> > -----Original Message-----
> > From: Andrew Hickson [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, May 30, 2002 12:27 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Problem receiving messages from a restarted client
> > applicatio n.
> >
> > MQCC_FAILED/MQRC_TRUNCATED_MSG_FAILED does not result in the message
>being
> > explicitly locked.
> >
> > I'm not sure if If I'm interpretting this discussion correctly, are we
> > discussing the following situation:
> >
> > App1 issues MQGET+wait with buffer length X
> > App2 issues MQGET +wait with buffer length Y
> > App3 issues MQPUT for message of length Z where X < Z < Y
> >
> > As a result of the MQPUT App1 is woken with MQRC_TRUNCATED_MSG_FAILED,
>but
> > does not reissue the MQGET with a bigger buffer. App2 is now waiting
>when
> > the message it's waiting for is already sitting on the queue.
> >
> > I would agree that this doesn't seem like a completely correct
> > implementation, although it does improve the chances of the message
>being
> > available if/when App1 reissues the MQGET with a correctly sized buffer,
> > and I think it is in accordance with the documentation of MQGMO_WAIT in
> > the
> > APRM. I'd be concerned that if I fixed the queue manager to wake up
> > another
> > waiting MQGET under these circumstances then some existing apps could
> > break. Any comments ?
> >
> > Andy.
> >
> >
> > "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002
> > 01:38:13 AM
> >
> > Please respond to MQSeries List <[EMAIL PROTECTED]>
> >
> > Sent by: MQSeries List <[EMAIL PROTECTED]>
> >
> >
> > To: [EMAIL PROTECTED]
> > cc:
> > Subject: Re: Problem receiving messages from a restarted client
> > applicatio n.
> >
> >
> >
> > >Actually I don't see why the larger messages that cause this problem,
> > >should ever have been locked or need a back-out as the get would be
> > failing
> > >on a 2080. When the client is not terminated and the surrogate can
>return
> > >the 2080, it does not prevent a new get from another client from
>getting
> > >the message.
> >
> > You raise an interesting question. If a get under syncpoint fails, does
> > the
> > candidate message become available to other processes immediately or is
>it
> > reserved until completion of the UOW. (By "candidate", I mean whatever
> > message would be returned if the MQGET had been successful). In the case
> > of
> > a RC=2080, at least, the MD gets filled out and you get part of the
> > message
> > back, despite the failure. Since, it's common place to obtain a larger
> > buffer and try the read again, I expect MQ withholds that message from
> > other
> > processes until it's "freed" by completion of the UOW. Honestly, this is
> > conjecture on my part, but it does explain part of the behavior you are
> > seeing.
> >
> > Also, I am curious, is your client MQGET a browse or destructive?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Richard Brunette [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, May 29, 2002 11:31 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Problem receiving messages from a restarted client
> > > application.
> > >
> > > Pavel
> > >
> > > I'm not sure that I understand what your saying. From everything I've
> > seen
> > > the syncpoint processing performs exactly as I would suspect and as
> > > documented in this usage note from the APR manual. Without
>syncpointing
> > > successful gets do lose the message when the 'surrogate' can't return
> > > them.
> > > And with syncpointing they are backed out and available for another
> > > program
> > > to browse or get.
> > >
> > > 3. If the application issuing the MQGET call is running as an MQ
> > > client, it is possible for the message retrieved to be lost if
> > > during
> > > the processing of the MQGET call the MQ client terminates
> > > abnormally or the client connection is severed. This arises
> > because
> > > the surrogate that is running on the queue-manager's platform
>and
> > > which issues the MQGET call on the client's behalf cannot
>detect
> > > the loss of the client until the surrogate is about to return
>the
> > > message to the client; this is after the message has been
>removed
> > > from the queue. This can occur for both persistent messages and
> > > nonpersistent messages.
> > >
> > >
> > > The risk of losing messages in this way can be eliminated by
> > always
> > > retrieving messages within units of work (that is, by specifying
> > the
> > > MQGMO_SYNCPOINT option on the MQGET call, and using the
>MQCMIT
> > > or
> > > MQBACK calls to commit or back out the unit of work when
> > processing
> > > of the message is complete). If MQGMO_SYNCPOINT is specified,
>and
> > > the
> > > client terminates abnormally or the connection is severed, the
> > > surrogate backs out the unit of work on the queue manager and
>the
> > > message is reinstated on the queue.
> > >
> > > I don't know that I've ever read anything to suggest that fully
> > backed-out
> > > message would under any circumstances not be available to another
>client
> > > that was already waiting on a get (let alone an open). In fact if I
>use
> > a
> > > smaller message in the test the already waiting client does get the
> > > message.
> > >
> > > Actually I don't see why the larger messages that cause this problem,
> > > should ever have been locked or need a back-out as the get would be
> > > failing
> > > on a 2080. When the client is not terminated and the surrogate can
> > return
> > > the 2080, it does not prevent a new get from another client from
>getting
> > > the message. It appears as though there is nothing to trigger the
>queue
> > > manger to check for the any outstanding gets that may be satisfied by
> > this
> > > message. A new get returns the message immediately. If the first
>client
> > is
> > > successful but backs the message out, then the second client's
>surrogate
> > > is
> > > given the message. The same is true if the first client's surrogate
>does
> > > the back-out. Why should if be different if the first client's
>surrogate
> > > fails to take the message?
> > >
> > > Rick
> > > 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
> >
> > 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
>
>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
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
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
