| Author |
Message
|
| Mogens Matthiesen |
 Posted: Thu Dec 18, 2008 3:05 am Post subject: 5 seconds delay on MQ-GET-WAIT. |
 |
|
Newbie
Joined: 12 Dec 2008
Posts: 5
|
Hi.
Any surgestions why some messages are staying 5 seconds in a local queue, before the application is able to get them.
The Q-manager is v6.0 and on z/OS. The applications involved are WebSphere application services/MQ Client connecting to a Server Connect channel.
Appl1 is putting a request on Q1, and does a get/wait on Q2 (wait-interval 5 seconds).
Immediately Appl2 gets request from Q1 and puts reply on Q2.
5 seconds later Appl1 gets the reply.
During the 5 seconds I se the reply in Q2, and I can get/browse it, but Appl1 dosn't get it until after 5 seonds.
We have tested the same WAS-application on a Windows Q-manager, and not seen any 5 second delay. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 18, 2008 3:24 am Post subject: Re: 5 seconds delay on MQ-GET-WAIT. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mogens Matthiesen wrote: |
During the 5 seconds I se the reply in Q2, and I can get/browse it, but Appl1 dosn't get it until after 5 seonds.
|
Browse it using what? Are you sure the message is being committed immediately? Or an implicit commit after 5 seconds?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mogens Matthiesen |
| Posted: Thu Dec 18, 2008 4:30 am Post subject: Re: 5 seconds delay on MQ-GET-WAIT. |
|
|
Newbie
Joined: 12 Dec 2008
Posts: 5
|
| Vitor wrote: |
| Mogens Matthiesen wrote: |
During the 5 seconds I se the reply in Q2, and I can get/browse it, but Appl1 dosn't get it until after 5 seonds.
|
Browse it using what? Are you sure the message is being committed immediately? Or an implicit commit after 5 seconds? |
I used the sample CSQ4BCG1 as a z/OS batch application, and printed the message! I didn't think I would be able to do that, if the message was not committed! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 18, 2008 4:42 am Post subject: Re: 5 seconds delay on MQ-GET-WAIT. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mogens Matthiesen wrote: |
| I used the sample CSQ4BCG1 as a z/OS batch application, and printed the message! I didn't think I would be able to do that, if the message was not committed! |
That sample, as supplied, prints and reads (rather than browses) messages. Hence you couldn't have used it to print the message, then watched your application read it after 5 seconds. Have you recompiled it to browse? Was the browse done within this 5 second wait window?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mogens Matthiesen |
| Posted: Fri Dec 19, 2008 6:44 am Post subject: Re: 5 seconds delay on MQ-GET-WAIT. |
|
|
Newbie
Joined: 12 Dec 2008
Posts: 5
|
| Vitor wrote: |
| Mogens Matthiesen wrote: |
| I used the sample CSQ4BCG1 as a z/OS batch application, and printed the message! I didn't think I would be able to do that, if the message was not committed! |
That sample, as supplied, prints and reads (rather than browses) messages. Hence you couldn't have used it to print the message, then watched your application read it after 5 seconds. Have you recompiled it to browse? Was the browse done within this 5 second wait window? |
Right, I have changed CSQ4BCG1 to get/browse, so that the messages will stay on the queue, when they are printet.
In several test-cases I submittet the print job 1-2 seconds before the button that activates Appl1 is pressed. In this way I managed to browse the message on Q2 two seconds after Appl2 had put it on the queue, and 3 seconds before Appl1 got it! |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 19, 2008 6:46 am Post subject: Re: 5 seconds delay on MQ-GET-WAIT. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mogens Matthiesen wrote: |
| [ In this way I managed to browse the message on Q2 two seconds after Appl2 had put it on the queue, and 3 seconds before Appl1 got it! |
All times from the job log I assume?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 19, 2008 6:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Any surgestions why some messages are staying 5 seconds in a local queue, before the application is able to get them. |
I missed the word some in your original post.
Are you saying that some reply messages are consumed in less than 5 seconds? Are throughput times for your gui client app consistently inconsistent? Or just sometimes?
Watch me make a guess: the requesting client application on the client platform is unable to keep up with the z/OS replying applicaiton.
Recall that the WMQ client layer propogates the MQGET/WAIT to execute on/in the qmgr. When the get/wait is satisfied (either by a message arriving or the wait timer popping), the client applicaiton must come back to life to consume the message (or receive the 2033 r/c).
So, tell me about the client platform and the network that connects them.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mogens Matthiesen |
| Posted: Fri Jan 02, 2009 2:19 am Post subject: Re: 5 seconds delay on MQ-GET-WAIT. |
|
|
Newbie
Joined: 12 Dec 2008
Posts: 5
|
| Vitor wrote: |
| Mogens Matthiesen wrote: |
| [ In this way I managed to browse the message on Q2 two seconds after Appl2 had put it on the queue, and 3 seconds before Appl1 got it! |
All times from the job log I assume? |
Put time (Appl1) is from the MD-header and stop-watch.
Print time is from the job-log.
Time that Appl2 receive message is from stop-watch. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 02, 2009 2:39 am Post subject: Re: 5 seconds delay on MQ-GET-WAIT. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mogens Matthiesen wrote: |
Put time (Appl1) is from the MD-header and stop-watch.
Print time is from the job-log.
Time that Appl2 receive message is from stop-watch. |
All these times are syncronised, and can't be affected by screen refresh / network latency to terminal / etc / etc / ?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mogens Matthiesen |
| Posted: Fri Jan 02, 2009 2:41 am Post subject: |
|
|
Newbie
Joined: 12 Dec 2008
Posts: 5
|
| bruce2359 wrote: |
| Quote: |
| Any surgestions why some messages are staying 5 seconds in a local queue, before the application is able to get them. |
I missed the word some in your original post.
Are you saying that some reply messages are consumed in less than 5 seconds? Are throughput times for your gui client app consistently inconsistent? Or just sometimes?
Watch me make a guess: the requesting client application on the client platform is unable to keep up with the z/OS replying applicaiton.
Recall that the WMQ client layer propogates the MQGET/WAIT to execute on/in the qmgr. When the get/wait is satisfied (either by a message arriving or the wait timer popping), the client applicaiton must come back to life to consume the message (or receive the 2033 r/c).
So, tell me about the client platform and the network that connects them. |
For this application, the reply-time is constantly 5.1 5.2 seconds, when we are testing against a Q-manager on z/OS.
I suspect, that in some way, the problem has to do with the get-wait, where the wait option is 5 seconds!
Because we don't see the problem, when the same application/client on the same Windows box is tested against a Q-manager on a Windows platform, I don't believe, that performance internally on the box, where the application/client is running, could be the problem. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 02, 2009 2:45 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
A MQGET with MQGMO_WAIT of 5 seconds will get the message immediately it is available.
It's more likely your application is performing a sleep type wait for 5 seconds (the dreaded polling interval) then doing a MQGET.
Change the time to 30 seconds and see what happens.
You could try coding MQPMO & MQGMO_NO_SYNCPOINT as well since the syncpoint default option differs from z/OS to other platforms (well done IBM for that one!) |
|
| Back to top |
|
|
|
|
