On 01/20/2012 05:50 AM, Jan MOEYERSONS wrote:
On Thu, 19 Jan 2012 10:21:01 -0600, Chase, John<[email protected]> wrote:
Occasionally, that MQ-draining transaction will be spawned nearly 1,000
times per second, and apparently "do nothing": No "I'm starting"
message, no "I'm finished" message, no ABEND, no nothing. SMF records
for these "phantom" transactions, formatted by CA-Sysview, show that
each instance starts the program, which then issues two MQOPENs (not
back-to-back), two MQCLOSEs (again, not back-to-back), one MQINQ, one
MQGET and one SQL SELECT, and then it ends "without comment". Average
task lifetime for these "phantoms" is around 8 milliseconds.
I think this may be related to the fact that an MQ triggering message is made
available to the initiation queue at the very moment the sending application
puts an MQ message on the queue, before this application message is committed.
Depending on how long it takes the batch program to commit its unit of work,
this may well result in the draining transaction firing up, finding its input
queue empty and ending again. Because there are still messages on the queue
(not yet available for draining, but they are there...) MQ then immediately
re-triggers the same. Over and over and over... until a message is actually
committed and thus becoming available to the drainer.
Simple solution to this problem is to have the draining transaction do its
first MQGET with a wait of say 250 to 1000 ms.
Cheers,
Jantje.
This sounds like a plausible explanation, but if true, isn't this a
design flaw in MQ that needs fixing? It makes zero sense for MQ to in
effect create a "busy" waiting loop that uses resources by having a
triggering mechanism repeatedly trigger a transaction for "available
message" before the message can actually be obtained, for reasons that
the observed transaction loop should make obvious. The resources
unnecessarily consumed by such "ghost" receiver transactions could even
potentially delay the sender from reaching the point of message commit
in a resource constrained environment.
If this design was a deliberate one to potentially allow faster response
by allowing a "long" receiver-transaction start up time to overlap with
a "short" sender time-to-commit, then at most MQ should trigger when the
message first enters, and if the corresponding MQGET arrives prior to
the commit and gets nothing (which obviously indicates a case where
time-to-commit is not "short", relatively speaking), trigger once more
only after the commit has occurred and the message can actually be
retrieved.
The suggested "wait" circumvention requires an application programmer to
be aware there is a problem that needs fixing. It would be better for
MQ design to prevent the problem in the first place.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
