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 IndexIBM MQ API SupportMQ Programming question about msg retrieval from queue

Post new topicReply to topic
MQ Programming question about msg retrieval from queue View previous topic :: View next topic
Author Message
dakoroni
PostPosted: Wed Jul 29, 2020 2:27 am Post subject: MQ Programming question about msg retrieval from queue Reply with quote

Apprentice

Joined: 10 Jan 2020
Posts: 41

Hello MQ API Support forum users,
I have the following question communicated to me from an app developer at customer site:

"I had the following rare case in message retrieval from a Windows MQ Queue in my C# program. My program asks a queue every second about its current depth.

If the depth is bigger than 0 then the program retrieves the messages, the amount of which is the queue depth. The case is that although the queue depth was 1, getting the message caused an exception with code 2033 (no message in queue). Why did this happen?

How happened that there was not a message to retrieve when the depth was 1?"

Any advise on the above question will be much appreciated.
Thanks in advance,
Rgds, Nick.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Jul 29, 2020 4:09 am Post subject: Reply with quote

Poobah

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

ReasonCode 2033 indicates "no message available," NOT that the queue is empty.

It is likely that the message(s) in the queue are currently in a unit-of-work transaction that has not yet committed.

Inquiring about queue depth is not a recommended practice, as it is NOT necessary, AND it imposes an additional MQ API call (MQINQuire). A better approach would be to do an MQGET (without first doing an MQINQuire), If there is a message available, the MQGET call will return it to the application.

It is recommended that your app specify MQGET with WAITinterval. If there is no message available, the call will wait until the WAITinterval expires, then return the 2033 "no message available." Repeat a reasonable number of times, then end the application. WAITing takes little overhead, while reloading the app takes substantial overhead. If a message becomes available BEFORE the WAITinterval expires, the app immediately consumes it.
_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Jul 29, 2020 4:32 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20394
Location: LI,NY

Also it looks to me like what you were doing is try to consume the messages until the queue is empty.

As my esteemed colleague specified the way to do that is to do a get with Wait and loop it until you either receive the 2033 reason code or return a null message (depends on interfaces being used). This by no means signifies that the queue is empty. It just means that there are no messages in a "gettable state" that match the retrieval criteria. Don't forget to clear the MQMsgId and MQCorrelId for each iteration of the loop.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Wed Jul 29, 2020 4:34 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26062
Location: Texas, USA

bruce2359 wrote:
Inquiring about queue depth is not a recommended practice. It imposes an additional MQ API call (MQINQuire). A better approach would be to do an MQGET (without first doing an MQINQuire), If there is a message available, the MQGET call will return it to the application.




Not only does it save an API call (and an inquire can be resource hungry) but depending on the platform, the get with wait will signal that the app won't need anything until the wait ends so resources can be diverted.

Many developers don't use get with wait because their app "can't just sit there until the wait expires", mistakenly believing that the wait is some kind of MQ-equivalent sleep statement. As my worthy associate correctly points out, the wait is the maximum period of time the get call will sit still for a message. If a message becomes available within the wait interval, the message will be returned immediately.
_________________
Honesty is the best policy.
Insanity is the best defence.


Last edited by Vitor on Wed Jul 29, 2020 4:44 am; edited 1 time in total
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Jul 29, 2020 4:43 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26062
Location: Texas, USA

For the record and the benefit of future readers, I'd like to underline the point my worthy associate made - 2033 is not "no messages on queue", it's "no messages available".

In addition to the case he correctly states (message on queue but uncommitted), a common mistake is to incorrectly set (or fail to clear) the MQMD or options between calls. The MQGet call never returns "the first message on the queue" but "the first message on the queue which matches the criteria passed to the MQGet call".

In most cases these criteria are blank so the match is in fact the first message on the queue. But consider if you're looking for a reply and so you've set the MQGet call to match a specific correlation id. That may not be the first message on the queue, but it still gets returned to the call.

Fail to clear that out before you try to read "the first message" of another queue and you'll get a 2033 because the call is looking for a specific correlation id it will never find.

Point to bear in mind.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Jul 29, 2020 7:24 am Post subject: Reply with quote

Poobah

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

This question has been posted here quite a few times in the past. Developers feel that they need to know how many messages are in the queue before they issue the MQGET call.

Oddly, developers do not demand to know how many records/bytes to read before issuing a READ statement against a sequential file. In this case, the o/s provides the EOF (end-of-file) indication when there is no more data to read.
_________________
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: Wed Jul 29, 2020 4:24 pm Post subject: Re: MQ Programming question about msg retrieval from queue Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2173
Location: Melbourne, Australia

dakoroni wrote:
Hello MQ API Support forum users,
I have the following question communicated to me from an app developer at customer site:
"I had the following rare case in message retrieval from a Windows MQ Queue in my C# program. My program asks a queue every second about its current depth.
If the depth is bigger than 0 then the program retrieves the messages, the amount of which is the queue depth. The case is that although the queue depth was 1, getting the message caused an exception with code 2033 (no message in queue). Why did this happen?
Thanks in advance,
Rgds, Nick.

The reason is lack of MQ understanding. Consumer apps generally do not have any need to query the current depth of the queue. If they do, it is incorrect usage to then try to get that number of messages.

As already mentioned, the correct approach is to just try to get a message (usually with a Wait Interval - the max time to wait for the next message to become available on the queue). If no message becomes available (Reason Code 2033) within the wait interval, go an do something else for a while, or try again. It is as simple as that!

Its quite valid to use an unlimited wait interval, or a zero wait interval, depending on your app design. Most pure MQ consumer threads will use an unlimited wait interval.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Jul 29, 2020 6:10 pm Post subject: Re: MQ Programming question about msg retrieval from queue Reply with quote

Poobah

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

dakoroni wrote:
If the depth is bigger than 0 then the program retrieves the messages, the amount of which is the queue depth.

What will your app do if 10 more messages arrive on the queue after the app MQINQuires on queue depth?
_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ API SupportMQ Programming question about msg retrieval from queue
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.