| Author |
Message
|
| mgrabinski |
 Posted: Fri Nov 22, 2002 1:20 am Post subject: MQPUTs and MQGETs |
 |
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Hi
We ran an MQ test last night. We made a loop on our mainframe queue manager (v5.2) so that messages coming from a remote queue manager were immedialtely send back (via qremote definition, no app involved). I had MQ trace running during the test. In the end it showed 2 times more GETs than PUTs (in each measuring interval). I'm sure that the manager wasn't used by anyone else. Can anyone explain it? Why each coming message generated two gets per each put?
TIA
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
 |
| pgorak |
| Posted: Fri Nov 22, 2002 5:58 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
One more thing - the trace does not show exactly 2 GETs for each PUT, but oscilates around that, e.g.:
PUTs: GETs:
22502 11255
22694 11346
23135 11562
23265 11632
23329 11660
There was send and receive exit involved, but I believe this should not affect the number of PUT and GET operations.
Any ideas?
Piotr |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Nov 22, 2002 5:59 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Well. Need more info at the first place. What did you trace. Meaning which process. And whats the exact setup.
From what i understand is you were tracing the reciever on your Mainframe qm. And that you saw 2 gets for each message being put at the other end. Which means, you saw receiver trying to read the message say 4 times for 2 puts at the other end.
If this is the case, it looks suspicious. I am not sure of what is going on.
Check for a possibility that the getter is a waited get and the waitinterval is less than the time taken for the other end to send the message put by the app.
Just a guess.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 25, 2002 6:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Is the app coded to MQGET with a small buffer, and to re get with a bigger buffer if it gets a truncated message error?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| pgorak |
| Posted: Tue Nov 26, 2002 1:52 am Post subject: Re: MQPUTs and MQGETs |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
Please read again:
| mgrabinski wrote: |
| messages coming from a remote queue manager were immediately send back (via qremote definition, no app involved) |
Piotr |
|
| Back to top |
|
|
| udaybho |
| Posted: Tue Nov 26, 2002 6:16 am Post subject: |
|
|
Voyager
Joined: 09 May 2002
Posts: 94
Location: Chicago
|
Your stat is showing more PUT's
PUT's = 2 * GETs. However you are saying the other way.
Probably your COBOL program did one put in remote queue, followed by an internal put to Transmit queue by MQ. But I am not sure.
Uday Bhosle |
|
| Back to top |
|
|
| pgorak |
| Posted: Tue Nov 26, 2002 7:00 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
| udaybho wrote: |
Your stat is showing more PUT's
PUT's = 2 * GETs. However you are saying the other way.
|
Right! My mistake... So the stats are in fact:
GETs: PUTs:
22502 11255
22694 11346
23135 11562
23265 11632
23329 11660
One cannot measure put/get frequency on a remote queue (just as one cannot measure the depth of a remote queue).
As said before, there was no application involved on the mainframe.
Piotr |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Nov 26, 2002 1:04 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
You are correct, you cannot measure the depth of a remote queue; however, you CAN measure the depth of the transmission queue associated with that remote queue. Here's what I'd do: stop the sender channel which the second queue manager uses to send the replies back to the first queue manager. This way, the messages will pile up on the transmission queue. Run your test, and you'll be able to compare the number of messages on the returning transmission queue with the number of messages that were MQPUT during the test. If there are MORE messages, then we clearly have some major problem. At that point, I'd start browsing through the transmission queue to compare the message contents with what you'd expect. In the more likely case that the number of messages on the transmission queue is the same as the number of messages you put in the first place, then I'd think that your method of measure the number of gets/puts must be flawed...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Wed Nov 27, 2002 4:08 am Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
To clarify all doubts (BTW - thanks for your responses!) the setup was as follows:
QM1:
QREMOTE(Q_AT_QM1) RQMNAME(QM2) RNAME(Q_AT_QM2)
QLOCAL(QM2) USAGE(XMITQ)
QM2:
QREMOTE(Q_AT_QM2) RQMNAME(QM1) RNAME(Q_AT_QM1)
QLOCAL(QM1) USAGE(XMITQ)
In this way, there is an infinite loop between the managers. Put a couple of messages into one of the above queues, and they will be running forth and back between the managers forever (unless channels go down). There is no aplication involved (except the initial PUTs and final GETs), all MQPUTs and MQGETs are internally done by MQ channels.
I was responsible for the mainframe part in the loop. Before the test I started the supplied MQSeries trace (can it be flawed?) and used a support pack (MP1B if I remember correctly) to get the statistic and accounting data from SMF. All data I got is satisfactory, except the mysterious number of GETs.
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| Bill57 |
| Posted: Wed Nov 27, 2002 11:16 am Post subject: |
|
|
Apprentice
Joined: 26 Jul 2002
Posts: 35
Location: Atlanta, GA
|
This is just a "stab in the dark", but, is there any evedence in the trace that the sender MCA is having trouble getting the message accross in the first shot and backs it out to the tranmit queue, then re-gets it? If possible, check the backout counter in the MQMD header to see if thats what's going on.
Good Luck
_________________
Bill Anderson
MQSeries Developer |
|
| Back to top |
|
|
| blowbeat |
| Posted: Thu Nov 28, 2002 12:56 am Post subject: |
|
|
Apprentice
Joined: 02 Apr 2002
Posts: 49
|
Did you run an accounting trace ?
If so, on the output of MQ116S (from MP1B) you should get details for the XMIT Q. What does it say for Total Requests and GETs-Valid ?
Maybe for each message there is a Valid & an Invalid get. An valid get is defined as a get that returns a message.
Cheers, Jan. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Nov 29, 2002 1:08 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Double gets can be explained by the use of MQGMO_SET_SIGNAL.
A get is issued with MQGMO_SET_SIGNAL but no message is immediately available so the Get returns with MQRC_SIGNAL_REQUEST_ACCEPTED and the caller does other stuff and eventually waits for the signal event to be posted. When it is posted the caller needs to reissue the MQGET to actually receive the message - so up to two gets per message (less if messages are immediately available).
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
|
|
