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 » False Positives?

Post new topic  Reply to topic
 False Positives? « View previous topic :: View next topic » 
Author Message
klamerus
PostPosted: Thu Feb 03, 2005 8:02 am    Post subject: False Positives? Reply with quote

Disciple

Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI

I recently became aware of an issue with our application that makes use of WebSphere MQ. One of my developers took a stab at explaining this to me that left me dubious. This is all on MS Windows 2000 with an application written in MS Visual C/C++ against MQ 5.3.

What he's claiming is that when queried, the MQ API will occasionally report that there is a message in the queue, when there is not resulting in a subsequent request to pull that message failing.

The code that checks is:

if ( (long) pInputQueue -> currentDepth() > 0) {do work}

and the error message on the request for the message is 2033.

This sounds very suspicious. Is there any known issue of this type or is there a practice that is often done wrong where people think this is happening and it's not (basically code or logic error)?
Back to top
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger
jefflowrey
PostPosted: Thu Feb 03, 2005 8:16 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

It's certainly not the recommended way to determine when to stop processing.

Among other things, current queue depth is affected by messages that are in an uncommitted state.

The recommended way is to wait for a 2033, and then stop processing.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
klamerus
PostPosted: Thu Feb 03, 2005 4:02 pm    Post subject: Reply with quote

Disciple

Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI

I think you're confused.

We have code that at certain points needs to check ans see if there is work to process (meaning items in the queue).

The code does the check via currentDepth() and if it gets a return code of > 0 (meaning there's work), it then tries to pull off a message.

That's when it gets the error message 2033 because there is nothing on the queue.

At least that's the story from my developer. I'm suspicious that something else is going on. I can't imagine why a check on the depth of the queue would report > 0, and yet nothing is there, but that's hiw claim.

So, that's what I'm asking about. Has anyone ever heard of a situation where the MQ API returns that there is a message in the queue, but there actually isn't?
Back to top
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger
PeterPotkay
PostPosted: Thu Feb 03, 2005 5:22 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

klamerus wrote:

At least that's the story from my developer. I'm suspicious that something else is going on. I can't imagine why a check on the depth of the queue would report > 0, and yet nothing is there, but that's hiw claim.


MQ as designed.

If the message expired,and no one did an MQGET for that message yet, the queue depth is 1, but when you do the MQGET, you get the 2033, because there is no valid message.

If the message is not expired, but not committed, the depth is 1, but you get a 2033 when you do the MQGET, because you cannot get an uncommitted message.

If the message is on the queue, not expired, and it IS committted, and it has a Message ID of BART, but your MQGET is specifying a MQMD.MEssageID of HOMER, the GET will fail, because there is no message on the queue with a Message ID of HOMER. (Same goes for Correl ID).

When its time to check the queue to see if there is any work, it is 100% WRONG to check the depth, and if >0, try a GET. First, its a waste of processing to issue an MQINQ just to do an MQGET. Second, you get false positives as you have found out.

Jeff was correct. Whe its time to check the queue for work, go directly to the MQGET. If there is a valid message that meets your criteria, you will get it. If there isn't, you get the 2033, and you go back to sleep. Who cares what the depth is, was or is going to be??? Better yet, just do an MQGET with a long WAIT, and don't bother polling. Polling is again a waste of processing.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
klamerus
PostPosted: Thu Feb 03, 2005 5:31 pm    Post subject: That's the ticket Reply with quote

Disciple

Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI

Now that's the kind of reply I really needed. I very much appreciate both the help and the helpful explanation of it.
Back to top
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

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