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 Index » IBM MQ API Support » MQ Programming question about msg retrieval from queue

Post new topic  Reply 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

Acolyte

Joined: 10 Jan 2020
Posts: 50

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: 9394
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.
_________________
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
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: 20696
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: 26093
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: 26093
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: 9394
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.
_________________
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
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: 2492
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: 9394
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?
_________________
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
View user's profile Send private message
Thomasbourl
PostPosted: Tue Oct 24, 2023 9:44 pm    Post subject: - Reply with quote

Newbie

Joined: 16 Oct 2023
Posts: 1
Location: Gibraltar

There is substantial discussion on the forum about the Q parameters. You might start by looking at the introduction to the different parameters and what they do.

You will see from people's signatures that there are few variations on what works best for different set ups.

R.
Back to top
View user's profile Send private message Send e-mail AIM Address
gbaddeley
PostPosted: Wed Oct 25, 2023 2:40 pm    Post subject: Re: - Reply with quote

Jedi

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

Thomasbourl wrote:
There is substantial discussion on the forum about the Q parameters. You might start by looking at the introduction to the different parameters and what they do.
You will see from people's signatures that there are few variations on what works best for different set ups.
R.

This thread does not mention Q parameters. Signatures do not contain variations on what works best. First post. Troll?
_________________
Glenn
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ API Support » MQ 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.