ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ Match with a wait

Post new topicReply to topic Goto page 1, 2  Next
MQ Match with a wait View previous topic :: View next topic
Author Message
bobbee
PostPosted: Tue Jun 16, 2020 10:56 am Post subject: MQ Match with a wait Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 458
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
View user's profile Send private message Send e-mail AIM Address
PaulClarke
PostPosted: Tue Jun 16, 2020 12:00 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 974
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
View user's profile Send private message Visit poster's website
bobbee
PostPosted: Tue Jun 16, 2020 12:17 pm Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 458
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
View user's profile Send private message Send e-mail AIM Address
PaulClarke
PostPosted: Tue Jun 16, 2020 12:23 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 974
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
View user's profile Send private message Visit poster's website
bobbee
PostPosted: Tue Jun 16, 2020 12:32 pm Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 458
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
View user's profile Send private message Send e-mail AIM Address
PaulClarke
PostPosted: Tue Jun 16, 2020 12:55 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 974
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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Tue Jun 16, 2020 12:56 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8771
Location: US: west coast, almost. Otherwise, enroute.

Misread the OP. Posted too soon.
_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Jun 16, 2020 1:40 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8771
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.

_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Tue Jun 16, 2020 3:01 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2154
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
View user's profile Send private message
PeterPotkay
PostPosted: Tue Jun 16, 2020 4:40 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7624

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
View user's profile Send private message
hughson
PostPosted: Tue Jun 16, 2020 8:31 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1489
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
View user's profile Send private message Visit poster's website
bobbee
PostPosted: Wed Jun 17, 2020 3:31 am Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 458
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
View user's profile Send private message Send e-mail AIM Address
hughson
PostPosted: Wed Jun 17, 2020 4:52 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1489
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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Wed Jun 17, 2020 5:04 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20385
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
View user's profile Send private message Send e-mail
bobbee
PostPosted: Wed Jun 17, 2020 5:15 am Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 458
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
View user's profile Send private message Send e-mail AIM Address
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ Match with a wait
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.