| Author |
Message
|
| yslee2 |
 Posted: Mon Jul 10, 2006 6:28 am Post subject: Need your help[urgent] |
 |
|
Newbie
Joined: 10 Jul 2006
Posts: 8
|
i have found the problem, but havent got the solution yet, please help me out
I got a stupid program which collect message from a queue by a while(true) loop, i set the gmo to be MQGMO_WAIT, waitInterval to be MQWI_UNLIMITIED,
the problem is that, when i kill the program by ctrl+c or sth like that, the opened queue isnt close, so next time a message is put on the queue, the message is get by the apparantly-dead queue, so it appear that the message is lost.
Please help me out if you know a solution. I think that it is okay if I set the gmo to be MQGMO_NOWAIT, but it seems that it would eat up all the cpu resource, so i would like to block for accepting message. |
|
| Back to top |
|
 |
| elvis_gn |
| Posted: Mon Jul 10, 2006 6:45 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi yslee2,
You are waiting for multiple messages, plus you are waiting for unlimited time...
Can you post your code and tell us what ur requirement is, also who else is listening on the queue.
Regards. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 10, 2006 6:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
There are so many solutions it boggles the mind, but a key question is this: how do you want to stop your program? How do you know you've finished and can stop processing? If the program needs to sit there for ever and ever, world without end, etc then specify FAIL_IF_QUIECISING on the call and bring it down with the queue manager. If it needs to sit there until you tell it to stop, code it to accept a "stop" message and devise a way to add it. Or set a wait interval and get it to check (in the gaps between waits) if it should stop by means of an environment variable / database value / semaphore value / smoke signal / etc.
You're quite right - MQGMO_NOWAIT is a good way to chew CPU. Don't use it.
I'll leave better minds than mine to explain why the connection isn't closed when you ctrl-c. My Java is not 1st class (I'm guessing this is in Java because of where you're posting - a clue in the posting would be nice) and I suspect you can code something in the connection factory or exception block to close the handle to the queue within the queue manager. But it's only a suspicion. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| yslee2 |
| Posted: Mon Jul 10, 2006 6:55 am Post subject: |
|
|
Newbie
Joined: 10 Jul 2006
Posts: 8
|
my code is sth like that:
| Code: |
....
while(true){
MQMessage msg = new Message();
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = MQC.MQGMO_WAIT;
gmo.waitInterval = MQ_MQWI_UNLIMITED;
queue.get(msg, gmo);
}
.... |
the requirement is quite loose, but when I test on my pc with the MQGMO_NOWAIT option, the system become unstable...
the line "queue.get(msg, gmo);" is blocked even I kill the process, queue is not closed
Therefore next time when i start my program, the first message is get by the left-over queue but not the new queue |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 10, 2006 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Okay, now I'd like to repeat that my Java is not that good and you should bear this in mind whilst reading.
Having said that, why are you creating a new Message & gmo object each time you go through the loop? Can't you reuse the one from the previous itteration? Or at least delete it to recover the memory?
It's clear that something beyond my comprehension is failing to respond to the ctrl-c signal by closing the queue handle. I repeat my previous comments - how do you WANT to stop it? I can't believe a prod strength program is closed from a keyboard by an opperator!
As elvis_gn says, tell us your requirements. It's all very well that they're "quite loose", but what are they? What are you attempting? Where is it running? What are the limitations?
There are so many possible solutions to this you'll need to narrow it down a bit.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| yslee2 |
| Posted: Mon Jul 10, 2006 7:33 am Post subject: |
|
|
Newbie
Joined: 10 Jul 2006
Posts: 8
|
the requirements are:
- get message from a queue, put a reply on another queue ASAP
- run 24x7 until a system reboot which i believe should be once a week
- since this program is new, but the mission is quite critical, it may happen that the program may end prematurely, which maybe be simulated by a ctrl+c.. so i think i have to make my program to clean-up all the things which may affect the next running of the program.
i got 2 possible solutions
- either making the the wait interval to be shorter, but i dont like the error printed on the system.out every once in a while.
- add some code to handle all possible exit conditions and do the clean-up work before exiting, but this may be quite complicated
i wonder if there is a GMO which block indefinitely but will be unlocked once the program exit... if there is one |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 10, 2006 7:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| yslee2 wrote: |
it may happen that the program may end prematurely, which maybe be simulated by a ctrl+c.. so i think i have to make my program to clean-up all the things which may affect the next running of the program.
|
So you need a passing Java person to talk about cleaning up dead queue and connection objects - beyond me I think. All I can say is open the queue non-exclusive and wait for the other connection to time out! 
Question - if it does fail, what restarts it? Can that be pressed into service to clean up the failing thread?
(And don't forget the quiesce options if there's a planned restart)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 10, 2006 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| yslee2 wrote: |
i wonder if there is a GMO which block indefinitely but will be unlocked once the program exit... if there is one |
Not unless there's a Java-specific one....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Jul 10, 2006 7:54 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| yslee2 |
| Posted: Mon Jul 10, 2006 8:12 am Post subject: |
|
|
Newbie
Joined: 10 Jul 2006
Posts: 8
|
thank you, that helps a lot
Thanks all of you who guided me to the solutions.
My decision is set the waitInterval to be 500millisecondes, and void all the exception printing. Hope that future version of MQ can bind the queue to a running process so that the queue and all the occupied resources can be closed automatically |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 10, 2006 3:49 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
because when you issue a Get With Wait, the code executing at the QM on the queue is not waking up every millisecond to see if your program is stil alive. So when you kill your app, you left behing the "thing" at the queue still waiting for a message. When the message finally arrives, the "thing" picks up the message, trys to hand it to your program, and finds it can't, so it throws away the message.
The solution is to issue your Get With Wait under syncpoint. Now when the message is picked up off the queue and your program is gone (for whatever reason, good or bad, intentional or not), the message will be rolled back to the queue.
If you care about your messages, get them under syncpoint! Do this regardless of whether you implement the other suggestions in this thread. All good suggestions, but they will not eliminate your problem completly. Now go, quickly, and code syncpoint on that get. Its URGENT!!!! 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
