Author |
Message
|
bobbee |
Posted: Tue Jun 16, 2020 10:56 am Post subject: MQ Match with a wait |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
If you issue an MQGET using a MATCH on CorrelID and a Wait time of 10 seconds. What happens?
1 - Tries to match and returns imed. Ignores the wait?
2 - spends up to 10 seconds trying to match. Does it loop searching the Queue? |
|
Back to top |
|
 |
PaulClarke |
Posted: Tue Jun 16, 2020 12:00 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Well the trite answer would be to say "why don't you just try it ?" We have an API Exerciser which is perfect for this
However, the answer is the latter. If you think about it it has to be that way. First of all it would be annoying to specify a wait and have it ignored but it would make writing many applications almost impossible (without continually polling anyway). Doing a GET(WAIT) with a particular CORRELID is very common. MQ Channels in a cluster do this ALL THE TIME. Many client application, particularly if they share a reply queue, do this too.
Of course if you have tried it and the MQGET is returning too fast remember that the parameter is in milliseconds. So, you need to specify 10,000 in your case.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
bobbee |
Posted: Tue Jun 16, 2020 12:17 pm Post subject: |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
WEll, if I went off and tried it, nobody on MQSeries.net nor the world could benefit. What is the fun in that.
But I am also wondering what MQ does under the covers. If FIFO order, does he, and some woman took offense to that fact we call MQ 'he' the other day on a call, know he ran the queue and sits there waiting to pounce. Or is there a continuous scan. Which I would think most inefficient and not the Hursley way.
Yes, I will not leave this here and go off to my little corner of hell and try this. Thanks. |
|
Back to top |
|
 |
PaulClarke |
Posted: Tue Jun 16, 2020 12:23 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
No there isn't a continuous scan. I don't really see the difference between "waiting for a message" and "waiting for a message which matches a certain set of criteria". If you are happy that MQ would not just continually scan waiting for a message then I don't see why you would think that MQ would suddenly start polling just because you are looking for a particular CORRELID.
Of course there can be performance ramifications when using any match criteria, especially if you have a deep queue, but not of the type you are alluding to.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com
Last edited by PaulClarke on Tue Jun 16, 2020 12:33 pm; edited 1 time in total |
|
Back to top |
|
 |
bobbee |
Posted: Tue Jun 16, 2020 12:32 pm Post subject: |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
1000 connections from DP, 1000 of messages a second pushing back and forth through the queues and DP issuing MQGET w/ Wait and a MATCH ON CORRELID. It has implications. Which is what I am investigating. The right approach generates the right solution.......pondering! |
|
Back to top |
|
 |
PaulClarke |
Posted: Tue Jun 16, 2020 12:55 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Well it won't if you have a GET(WAIT) interval which is the question in the original post.
I am not quite sure the point you are making Bruce. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Jun 16, 2020 12:56 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Misread the OP. Posted too soon. _________________ 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 |
|
 |
bruce2359 |
Posted: Tue Jun 16, 2020 1:40 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
The MQGET call does not drive looping or polling for messages in a queue.
From https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.tro.doc/q041040_.htm for MQ R/C 2033:
Quote: |
An MQGET call was issued, but there is no message on the queue satisfying the selection criteria specified in MQMD (the MsgId and CorrelId fields), and in MQGMO (the Options and MatchOptions fields). Either the MQGMO_WAIT option was not specified, or the time interval specified by the WaitInterval field in MQGMO has expired. |
The WaitInterval value tells MQ how long to Wait (not poll) for a message to arrive in the queue; after which, if no message arrives, the MQGET call will end - returning control to the application.
From https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q026420_.htm
Quote: |
If you want a program to wait until a message arrives on a queue, specify the MQGMO_WAIT option in the Options field of the MQGMO structure.
Use the WaitInterval field of the MQGMO structure to specify the maximum time (in milliseconds) that you want an MQGET call to wait for a message to arrive on a queue.
If the message does not arrive within this time, the MQGET call completes with the MQRC_NO_MSG_AVAILABLE reason code. |
_________________ 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 |
|
 |
gbaddeley |
Posted: Tue Jun 16, 2020 3:01 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
bobbee wrote: |
1000 connections from DP, 1000 of messages a second pushing back and forth through the queues and DP issuing MQGET w/ Wait and a MATCH ON CORRELID. It has implications. Which is what I am investigating. The right approach generates the right solution.......pondering! |
Hi Bobbee. You can be assured that the internal behavior of MQ is highly optimised for this scenario and many others. Matching on msgid or correlid is handled by internal indexing and in-memory buffering of messages, but if the depth of the queue is high (say 100's - 1000's YMMV) there may be non-optimal performance. Usually it is the application design that impacts performance, not MQ per se. _________________ Glenn |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jun 16, 2020 4:40 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
I think its an interesting question.
The way I ASSume it works is when the MQGET with Wait with a Match is issued, the Queue Manager first scans the queue from oldest to youngest message already on the queue (deferring to priority) and if no match, then waits for the Wait Interval. As new messages are placed on the queue, the Queue Manager knows it has an outstanding Get With Wait with Match and double checks to see if the new message satisfies this criteria or not. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
hughson |
Posted: Tue Jun 16, 2020 8:31 pm Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
PeterPotkay wrote: |
The way I ASSume it works is when the MQGET with Wait with a Match is issued, the Queue Manager first scans the queue.... |
The word "scans" is probably the pertinent part of your assumption here.
The queue manager does not have to scan the whole queue to discover if a message matches the requested MsgId or CorrelId. Internally the queue manager has "indexes" to allow for a much more efficient way to determine that without scanning the whole queue. On z/OS you have to configure these indexes to say whether you need one for MsgId or CorrelId for a specific queue. On distributed platforms you don't as both indexes are created as a matter of course.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
bobbee |
Posted: Wed Jun 17, 2020 3:31 am Post subject: |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
Yeah, I was hoping and thinking that it was a scan and then some 'smarts' for the remainder of the query. I have used it this way for a long time and never thought deeper because it was a limited set of messages. I have DP involved with 1,000 connections and all this get w/wait going on and they are questioning performance. I wish I have a copy of the flow diagram. Lot of crazy back and forth from IIB to DP using MQ for XSL transformation.
I see said the blind man to the deaf man.
Thanks ALL for the input. |
|
Back to top |
|
 |
hughson |
Posted: Wed Jun 17, 2020 4:52 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
Perhaps it would help if you described to us what the performance issue you're seeing is? Rather than guessing at a cause and asking the question about whether this cause could be your problem. We might be able to suggest other things to look into based on a description of the problem.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jun 17, 2020 5:04 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Well looking at IIB for XSL Transformation might not be the most efficient use of IIB either. I would expect using a map or an ESQL transformation could be faster...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bobbee |
Posted: Wed Jun 17, 2020 5:15 am Post subject: |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
I asked this yesterday about IIB and transformation. The DP chimed in quickly, 'Transformations on the wire'. Always wonder what that meant. I mean you have to read it in, transform in memory (supposedly it is 4 meg xst) and then push it out.
But there are several, maybe 3-4, back and forth interactions from IIB to DP. There has to be some incurred latency. I do not have a rock solid understanding yet, but the flow diagram made my head spin. |
|
Back to top |
|
 |
|