| Author |
Message
|
| wmussante |
 Posted: Tue Jul 29, 2003 4:19 am Post subject: GET with Unlimited Wait |
 |
|
Newbie
Joined: 29 Jul 2003
Posts: 2
Location: Silver Spring, MD
|
| Normally I want the MQGET to block my application until a message arrives. However I also want my application to be interruptible so I have written a signal (interrupt) handler. In the interrupt handler I change the wait interval to something small so MQ will stop blocking and I can respond to the interrupt. But MQ doesn't seem to recognize that I have changed the wait interval. I also tried setting the Options to MQGMO_NO_WAIT in the interrupt handler but to no avail. How can I make the GET stop blocking? My understanding is that I should do very little in the signal handler itself. |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Tue Jul 29, 2003 5:53 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Dont think you can do that at all the way you are trying. Reason. When you issue a waited_get, MQ waits indefinitely until a message arrives on the queue in question. Only when it gets a message, it replies to the application. Hence until then, the app is sort of hung. Which is what you wanted to do when you issued the get in your app with wait_unlimited. So, you are trying to change your own design at run time, which is kind of going out of the way thing.
If you think there is a possibility of you needing the control back in your get app, Dont do a wait_unlimited. Instead do a waited get.
BTW, how did you presumably try to "reset" the gmo options for the get that is already in progress or rather waiting unlimited???
Cheers
Kumar |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jul 29, 2003 7:41 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
From the MQSeries Manual
Asynchronous signals
Asynchronous signals arise outside the whole process. UNIX does not guarantee predictable behavior for handling asynchronous signals, in certain situations, when running multithreaded. MQSeries must perform clean-up of thread and process resources as part of the termination from these asynchronous signals:
SIGCHLD
SIGHUP
SIGINT
SIGQUIT
SIGTERM
MQSeries establishes a sigwait thread in the application process to intercept these signals.
These signals must not be used by the application when running multithreaded and when any thread is within an MQSeries connection. These signals should not be unmasked within any application thread; be aware of the default status of the signal mask for threads that do not make MQSeries calls.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 29, 2003 8:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Ideally, applications that do a GET with wait should always check the feedback field of the MQMD immediatly after every succesful GET.
MQSeries allows applications to communicate with one another through the feedback code in the message descriptor.
You long running app should be coded so that if the IBM supplied value of MQFB_QUIT is encountered in the feedback field, the app will gracefully end.
Now all you have to do is drop a "quit" message into the queue, and your app will end (or do whatever you coded it to do in that case).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 29, 2003 11:24 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's much easier just to use a wait interval of say 60 seconds. When it expires with "no msg available" then you check for your other events and if there are none then re-issue the GET WAIT for another 60 seconds and so on. If the get expires with a message to process obviously you deal with it before checking for other events and reissuing the GET. When a message arrives the wait immediately ends of course, the 60 seconds is a maximum wait time, not a fixed interval.
Simple. |
|
| Back to top |
|
|
| wmussante |
| Posted: Thu Jul 31, 2003 9:30 am Post subject: GET with Unlimited Wait |
|
|
Newbie
Joined: 29 Jul 2003
Posts: 2
Location: Silver Spring, MD
|
mqonnet: I coded a sigterm signal handler and the handler is entered when a signal is sent despite being in a unlimited wait. So I know that works but I can't seem to make MQ change from unlimited to limited after having executed it. I want to have my cake and eat it too. I was hoping that I might be able to have an unlimited wait and still handle this special and rare case of a signal.
mrlinux: I apologize for being ignorant of threads. As far as I know I am single threaded. The manual is addressing multi-threaded applications.
PeterPotkay and zpat: Not exactly what I was hoping but good ideas.
Thanks to all! |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Aug 01, 2003 1:11 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Are you on a platform that supports MQGMO_SET_SIGNAL?
If you could use this option MQ would signal your aplication when a message becomes available rather than entering a blocking wait.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| ekscnet |
| Posted: Wed Oct 15, 2003 8:08 am Post subject: |
|
|
Newbie
Joined: 15 Oct 2003
Posts: 2
|
| bob_buxton wrote: |
Are you on a platform that supports MQGMO_SET_SIGNAL?
If you could use this option MQ would signal your aplication when a message becomes available rather than entering a blocking wait. |
I was trying to find ANY information on how to use MQGMO_SET_SIGNAL within Windows 2K environment and higher using C++. So far all my attempts failed.  Any help will be appreciated.
Thanks,
EK |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed Oct 15, 2003 8:31 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
from the ibm manual program reference
This option is supported in the following environments: z/OS, Compaq NonStop Kernel, Windows 95, Windows 98
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| ekscnet |
| Posted: Wed Oct 15, 2003 10:08 am Post subject: |
|
|
Newbie
Joined: 15 Oct 2003
Posts: 2
|
Thanks Jeff.
Does this mean NT (including 2000 and XP) is "out of luck"?
Is there any place where I can get a sample code for handling MQGMO_SET_SIGNAL with C++ so I can do some testing?
Thanks again,
EK |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed Oct 15, 2003 11:29 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well I guess it does since I pulled it from the latest manuals, unless of course the manual is in error.
Iam not sure where to find samples
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Oct 15, 2003 1:51 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I thought this signal capability was in the MQSeries for Windows v2 product that was also called the leaf-node queue manager. I didn't think that it existed in the full-blown product. |
|
| Back to top |
|
|
|
|
