Rick,
I've discussed this with the mainframe developers (I'm one of the
developers on the MQ distributed products) and understand they have fixed a
number of problems in this area recently (I assume 5.3). The 390 product
has a couple of additional complications in this area (mark skip backout &
get with signal), and I think that all that might be required on the
distributed platforms is to avoid only waking a single waiter if the
waiters buffer is too small and doesn't want to accept a truncated message.
It might be sensible to awaken a waiter with a big enough buffer in
preference to waking both the waiter with a small buffer and the waiter
with a big buffer in my earlier example, but I'll make that decision when I
look at the code in detail.
It's now too late for this change to get in the first distributed 5.3
deliverable and I'd expect it to appear in the first 5.3 CSD. If you want
the fix earlier then you'll need to raise a problem with the support center
and the service team should be able to port the fix back to 5.2.
Andy.
Richard Brunette <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on
05/30/2002 04:03:32 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
application.
This application was simply using an indefinite wait. As I said we have
convinced the application developers to make a number of changes that with
provide a better design for their business problem. These changes have
greatly reduced the frequency that the application will be exposed to this
problem. However the problem still exists and is the type of issue that is
going to hit you and not necessarily be easily identified. The exposure
risk is going up with more java development with unspecified message
lengths.
As Andy says (and testing proves) the message isn't locked or considered
part of a unit of work. It is available to any get that comes along. It
just will not be delivered to a get that is already waiting for it, unless
there is another message that becomes available to tell the queue manager
to wake up the get that is waiting. I'm well aware of receiving the portion
of the message that fits in the buffer as Dennis mentions and even
questioned the idea of the message being locked myself, but its just not
the case.
It sounds like Andy understands both the issue and why the internals of the
queue manager code is causing this behavior. I'm assuming, from your many
past posts to this list Andy, that your one of the IBMers on this list with
detailed knowledge of the internal code-base of the mainframe queue
managers.
Thanks Pavel, Dennis, and Mike for you comments. Andy I'd like to hear any
further information on what will be done or what is to the expected
behavior of the queue manager and the surrogates in this situation. In
addition a co-worker here has sent IBM and ETR on this issue.
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
