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
