| Author |
Message
|
| vbajwa |
 Posted: Wed Jan 31, 2007 8:21 am Post subject: Reading from MQ with timeout (C++) |
 |
|
Newbie
Joined: 31 Jan 2007
Posts: 8
|
There are messages on the queue. When I connect my program, it gets the first message, then when I call ImqQueue::get() with a wait of 500ms, the get returns with a "false" and the completionCode() == MQCC_FAILED and the reasonCode is set to 2033. Following is the code fragment, the default wait is -1 (MQWI_UNLIMITED): When I wait forever, the call does not return, even though there are messages on the queue. Really appreciate any help on this! - Thanks, Vijay
bool MQReceiver::get (long msecs)
{
bool retCode = true ;
msg.clearMessage ();
if ( msecs == MQWI_UNLIMITED ) {
gmo.setOptions (MQGMO_WAIT);
gmo.setWaitInterval (MQWI_UNLIMITED);
}
else if (msecs == 0) {
gmo.setOptions (MQGMO_NO_WAIT );
}
else {
gmo.setOptions (MQGMO_WAIT );
gmo.setWaitInterval (msecs);
}
if ( !(retCode = ImqQueue::get (msg, gmo) ) )
{
if ( completionCode() == MQCC_FAILED) {
int reason = reasonCode ();
ERROUT << "MQReceiver::get failed for: " << qname << " reason code: "
<< reason << ENDL
throw GTSMQException ("get failed", (char*)queueManagerName(),
qname.c_str(), reason);
}
}
return retCode;
} |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jan 31, 2007 8:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
How do you know there are messages on the queue?
Also, you probably need to reset the MsgId and CorrelId between GETS.
In C++ probably best to create a new msg object each time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vbajwa |
| Posted: Wed Jan 31, 2007 10:11 am Post subject: |
|
|
Newbie
Joined: 31 Jan 2007
Posts: 8
|
| jefflowrey wrote: |
How do you know there are messages on the queue?
Also, you probably need to reset the MsgId and CorrelId between GETS.
In C++ probably best to create a new msg object each time. |
That worked beautifully, I mean, getting a new msg each time! Thanks! |
|
| Back to top |
|
|
| vbajwa |
| Posted: Wed Jan 31, 2007 10:32 am Post subject: Re: Reading from MQ with timeout (C++) |
|
|
Newbie
Joined: 31 Jan 2007
Posts: 8
|
Given the above code (in fiirst msg in thread) after I passed in a new message on each get() call, things started working fine with infinitw wait. However, when I pass a timeout value, ImqQueue::get(msg, gmo) returns with return value of false, which is surprising. Even more surprising is that completionCode() == MQCC_FAILED. Ofcourse reasonCode == 2033 because all messages have been drained out. First of all, IBM does not document return codes for calls, and I remember reading somewhere (on IBM site) that completionCode must be checked first, and then reasonCode is a qualification to completionCode.
Can the call reasonably be said to have "failed" if it timed out, with no message? So, I guess return code of false means "no message" and the call is deemed to have failed?
Thanks for any light on this! Regards, Vijay |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Jan 31, 2007 10:47 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| First of all, IBM does not document return codes for calls, |
Excuse me? Of course if does! Appendix A of the APG.
It is all very clearly documented....and there is even a handy, dandy return code analyser that runs on Windows to. That support pack is here
http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24000652&loc=en_US&cs=utf-8&lang=en
| Quote: |
Can the call reasonably be said to have "failed" if it timed out, with no message? So, I guess return code of false means "no message" and the call is deemed to have failed?
|
That depends on your application....but mostly a 2033 is worth knowing about I would think  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 01, 2007 7:45 am Post subject: |
|
|
Guest
|
MQGET with infinite wait is not a best practice. A normal (controlled) qmgr shutdown will never complete since the MQGET will never complete.
The usual programming for this is:
MQGET with a wait of some reasonable time period (a minute, for example);
check for completion-code failed; if failed, check for reason codes associated with MQGET;
if no-msg-available, then repeat the MQGET a reasonable number of times.
It is resource-intensive to launch the MQGETting application; but much, much less intensive to do the MQGET with wait loop.
Reason codes are well-documented in both the MQ Application Programming Reference, with coding examples. IBMs MQ website contains lots of sample programs, as well. |
|
| Back to top |
|
|
| tleichen |
| Posted: Thu Feb 01, 2007 8:20 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| bruce2359 wrote: |
MQGET with infinite wait is not a best practice. A normal (controlled) qmgr shutdown will never complete since the MQGET will never complete.
|
Sometimes I wonder why IBM even allowed an infinite wait. I can see how it was easy to implement. But, the consequences are just too undesirable for words. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 01, 2007 8:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
WaitInterval is an MQLONG. By my rough calculations, possibly off by a factor, the longest you can wait is about 25 days.
Some could argue that any program sitting around doing nothing for longer than 24 days is a process that should be triggered. I might even be one of those people - but there is still a valid reason for allowing a longer wait time than can fit in WaitInterval.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 01, 2007 9:19 am Post subject: |
|
|
Guest
|
As we ponder the unponderable... and I'm one of those guys.
From APG:
"The WaitInterval field specifies the maximum time (in milliseconds)..."
Perhaps a millisecond isn't a short enough wait time for some applications. Wait-unlimited would be the only solution.
Remember way back when a millisecond seemed pretty fast. With mid-range servers beyond GHz range, and mainframes now under 10 nanoseconds, a millisecond is an eternity. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Feb 01, 2007 9:20 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| MQGET with infinite wait is not a best practice. A normal (controlled) qmgr shutdown will never complete since the MQGET will never complete. |
As stated that is a little misleading.
...but it does depend on applications using the MQGMO "FAIL IF QUIESCING" option. If they use this option they will get a 2161 return code and can act accordingly. ie. close objects & disconnect (UOW permitting and if that is what is needed).
I always tell our programmers to specify this option and evaluate and code the business logic for this situation accordingly. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 01, 2007 9:46 am Post subject: |
|
|
Guest
|
Yep. From the APG again:
If the state of the queue or the queue manager changes before the wait interval expires, the following actions occur:
-If the queue manager enters the quiescing state, AND you used the MQGMO_FAIL_IF_QUIESCING option, the wait is canceled and the MQGET call completes with the MQRC_Q_MGR_QUIESCING reason code. Without this option, the call remains waiting. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 01, 2007 9:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bruce2359 wrote: |
| Perhaps a millisecond isn't a short enough wait time for some applications. Wait-unlimited would be the only solution. |
That doesn't make any sense at all.
The WaitInterval has always been, and remains, the maximum time to wait.
There is no solution for an application that needs to wait a maximum time that is LESS than one millisecond. Other than having a process that can fire off a "halt" message every necessary period.
Unlimited wait is a solution for an application that needs to wait MORE than the longest time that can fit into an MQLONG.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 01, 2007 10:14 am Post subject: |
|
|
Guest
|
From the APG:
This is the approximate time, expressed in milliseconds, that the MQGET call waits for a suitable message to arrive (that is, a message satisfying the selection criteria specified in the MsgDesc parameter of the MQGET call; see the MsgId field described in Chapter 12, “MQMD – Message descriptor,” on page 143 for more details). If no suitable message has arrived after this time has elapsed, the call completes with MQCC_FAILED and reason code MQRC_NO_MSG_AVAILABLE.
My app may need to do other stuff in the absence of a message arriving in under a millisecond. If that's the case, then you are right that MQ doesn't offer any solution. |
|
| Back to top |
|
|
| vbajwa |
| Posted: Fri Feb 02, 2007 1:24 pm Post subject: |
|
|
Newbie
Joined: 31 Jan 2007
Posts: 8
|
| bruce2359 wrote: |
| From the APG: |
Thank you very much for all responses. There are a million places where MQ API is documented, the one I use is very terse:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp topic=/com.ibm.mq.amqzan.doc/mgr.htm
Anyway, I thought a return of false, and completionCode() of MQCC_TIMED_OUT might have been more reasonable than MQCC_FAIL
Thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 02, 2007 4:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| vbajwa wrote: |
| bruce2359 wrote: |
| From the APG: |
Thank you very much for all responses. There are a million places where MQ API is documented, the one I use is very terse:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp topic=/com.ibm.mq.amqzan.doc/mgr.htm
Anyway, I thought a return of false, and completionCode() of MQCC_TIMED_OUT might have been more reasonable than MQCC_FAIL
Thanks |
Why? I think the rc is quite appropriate. You did not time out as the wait was cancelled by the qmgr shutting down. So MQCC_FAIL with qmgr quiescing is quite appropriate....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
