Andy
Your example is one way that I've been testing this. We actually ran into
the problem with a terminated JAVA client. The client was using the get
method in which the application does not specify the buffer size. For
messages larger that 4096 this is going to cause a 2080 that gets retried.
If the application terminates its the client's surrogate at the queue
manager that is getting the 2080 and its not going to turn around and issue
another get, likewise neither is the client that has long since stopped
going to issues the proper get.
Dennis, I wondered about that as well. This problem has made me question a
few things I thought I knew. But my testing has demonstrated what Andy is
saying, the message is not locked. I can issue a GET just after the put and
it will retrieve the message. It just doesn't work if the get is already
waiting.
Dennis as for your request for comments on fixing the queue manager to wake
up another waiting MQGET, here is my two cents. Any application that is
dependant on a guarantee that a 2080 message is still there already has
problems, because there is no such guarantee. To the best of my knowledge
IBM's manuals make no such promise. And in fact as long as the other
client's get happens after the put, or another messages is put to wake up
the sleeping task the message will be delivered (or attempted to be
delivered) to the other task(s). Furthermore the first message, the failed
message, is the first message retrieved by the sleeping task if a new
message wakes up the task.
So in keeping with the assured delivery promises that have actually been
made, I think you wake up the waiting thread and give it the message before
it expires or becomes pointless instead of trying to preserve a behavior
that is not promised or even reliable (like a 2080 maybe still being
there). A client's get should not hang just because it was already waiting.
Rick
|---------+--------------------------------------->
| | Andrew Hickson |
| | <[EMAIL PROTECTED]> |
| | |
| | Sent by: MQSeries List |
| | <[EMAIL PROTECTED]> |
| | |
| | |
| | |
| | Thursday May 30, 2002 02:26 AM |
| | Please respond to MQSeries List |
| | |
|---------+--------------------------------------->
>----------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| 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
