| Author |
Message
|
| ivanachukapawn |
 Posted: Fri Nov 03, 2006 7:08 am Post subject: GET with infinite wait interruptible? |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Our application has a child thread which does a GET with a 500ms wait. If 2033 then it loops back to do another GET with a 500ms wait.
This child thread is a 'server' and as such has a responsibility of dequeuing and processing any message arriving on the queue.
I want to change this design so that the child thread simply does a GET with an infinite wait. My question is: can I have this child thread do a GET with an infinite wait and still have the capability at the parent thread level of quiescing and stopping the child thread? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Nov 03, 2006 7:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Sure.
Create a "Quiesce" message.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 03, 2006 7:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I don't think you can terminate the wait except by externally terminating the thread. Specify FAIL_IF_QUIESCING in the get options and the wait will end when the queue manager does, but I don't think that's quite what you're looking for.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 03, 2006 7:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
Sure.
Create a "Quiesce" message. |
Doh..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 03, 2006 7:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No, you're right.
The only way to terminate a Get with Indefinite wait OTHER than having a message arrive is to either specify FAIL_IF_QUIESCING or externally terminate the thread and the MQ connection.
But having a message arrive is the better solution to the specific problem.
And anyone who codes a Get with Indefinite Wait and doesn't specify FAIL_IF_QUIESCING deserves to spend a year as an MQ Admin.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 03, 2006 7:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
But having a message arrive is the better solution to the specific problem.
|
It is, and I should have thought of it
| jefflowrey wrote: |
And anyone who codes a Get with Indefinite Wait and doesn't specify FAIL_IF_QUIESCING deserves to spend a year as an MQ Admin. |
I was once told "Why code that? You can just bounce the box if you want it to stop. Works fine for me". I explained with heroic restraint it took longer, and irritated more people, to bounce an HP-UX SecureGuard cluster than it took to bounce his laptop. 
(kill -9 is the best command ever) 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Nov 03, 2006 7:36 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
The only way to terminate a Get with Indefinite wait OTHER than having a message arrive is to either specify FAIL_IF_QUIESCING or externally terminate the thread and the MQ connection.
|
Or you could get disable the queue....drastic - sure, sloppy - you bet, but nonetheless effective and it keeps the queue manager up and running  |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Fri Nov 03, 2006 7:56 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
This problem has nothing to do with the Queue Manager quiescing or stopping. The requirement is that the parent thread must be able to stop the child thread despite the fact that the child thread has issued a GET with an infinite wait.
Note: Queueing a quiesce message is not a viable option. The queue in question will tolerate only validated Business Event XML messages under transaction control. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 03, 2006 8:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Then you're stuck with get disabling the queue (remembering to reenable it before restarting your app) or pulling the thread down with an external methodology
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Nov 03, 2006 8:52 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
ivanachukapawn
What platform are you wanting to do this on? It is possible to do what you want to programmatically on z/OS but I am not too sure about the other platforms.
What is the reason for changing the design? As with most MQ enabled applications it is usually the business needs that will eventually drive the solutions.
You wrote:
| Quote: |
I want to change this design so that the child thread simply does a GET with an infinite wait.
|
Why? What is not satisfying the business need in the old method?
If you truly want to be able to close the child thread down from it's unlimited wait from the main parent task then do as Jeff suggests, code the parent to drop a 'get the heck down' message to the child's queue, and code the child to shut itself down when it gets that message. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Fri Nov 03, 2006 10:11 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| The business need is satisfied with the current design. Its in software engineering that I want to make improvements. In this environment, upwards of 30 processes are consumers on queues using this design which generates a client<-->queue manager interaction every 500 ms. This is somewhat sub-optimal vs an optimal design which used GET with infinite wait. As I mentioned earlier, we do not have the latitude (permission) to queue anything other than registered Business Event XML messages to this queue. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 03, 2006 10:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Increase the wait timeout to 100000 ms, then.
And read about heartbeats.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Nov 03, 2006 11:15 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| The business need is satisfied with the current design. |
Then don't change it. 
| Quote: |
| Its in software engineering that I want to make improvements. |
Why? If it works, and it satisfies and fullfills the buniess need, leave it alone.
The statement:
| Quote: |
| we do not have the latitude (permission) to queue anything other than registered Business Event XML messages to this queue. |
Leads me to think that you don't have the business users buy-in for a major scope change so leave it alone unless it is failing.
What you are left with now if you want to go the unlimited wait route is either to kill the child processes or GET inhibit the queues, either way it will require some thought as to how to 'reset' things once this is done. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 03, 2006 3:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
Increase the wait timeout to 100000 ms, then.
And read about heartbeats. |
I like jeff's answer a lot. What I don't get is if the average idle time of the queue is 500ms why set the wait interval to 500ms?
You are not going to wait the full interval if you do get a message.
So boosting your interval to 100000ms gives you less CPU (outside of MQ) and still allows you to process the messages as they arrive.
Performance enhancement goal achieved. Worst case scenario: the parent process will have to wait 100000ms to shut down the child....
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Nov 04, 2006 9:12 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi ivanachukapawn,
Here's an example of someone who designed a system with some know of MQ. The reason the architect / developer used 500ms with the Get is because he/she understood you cannot internally break a Get Wait Forever. 
Now you want to alter the behavior of the application but you don't really understand MQ. Plus someone gave you an answer for interrupting a Get Wait Forever but you immediately discarded it.
| ivanachukapawn wrote: |
| This child thread is a 'server' and as such has a responsibility of dequeuing and processing any message arriving on the queue. |
| jefflowrey wrote: |
| Create a "Quiesce" message. |
| ivanachukapawn wrote: |
| Note: Queueing a quiesce message is not a viable option. The queue in question will tolerate only validated Business Event XML messages under transaction control. |
The word 'Quiesce" in this case means "Quit". And to elaborate on Jeff's comment, what he was trying to tell you is that there is an MQ Best Practice for terminating a Get Wait Forever.
A thread / program / whatever, puts an empty message on the queue with the MQMD's Feedback set to MQFB_QUIT.
Then in your child thread that reads the queue, you put the following:
| Code: |
if (msg.feedback == MQC.MQFB_QUIT)
{
return;
// or throw an exception - no message or time to quit ...
} |
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
