| Author |
Message
|
| jlamond |
 Posted: Fri May 05, 2006 4:58 am Post subject: runmqtmc looping on Solaris |
 |
|
Voyager
Joined: 28 May 2002
Posts: 94
Location: Paris
|
Hi,
Today for the first time, I found the MQ client trigger monitor (runmqtmc), looping on the same message. Initialy, I though that the situation was cause by a curdepth of one in the app. queue and the fact that the triggered application abend, this causing a curdepth moving from one to 0 and then back to one.
I had a second message in the queue and then restart the client trigger monitor program on Solaris and I got the same behavor - runmqtmc looping for ever and core dump from the application.
Anybody encounter something like that ?
Regards,
Jean-Marc
_________________
Jean-Marc |
|
| Back to top |
|
 |
| jlamond |
| Posted: Fri May 05, 2006 5:01 am Post subject: |
|
|
Voyager
Joined: 28 May 2002
Posts: 94
Location: Paris
|
trigger is set to first
_________________
Jean-Marc |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 05, 2006 5:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's not runmqtmc that's at fault, I think.
If the app is core dumping, then this is a real problem and should be fixed before anything else is considered.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jlamond |
| Posted: Fri May 05, 2006 5:47 am Post subject: |
|
|
Voyager
Joined: 28 May 2002
Posts: 94
Location: Paris
|
I do agree that the application should be corrected but this does not excuse an infrastructure component to fail...
_________________
Jean-Marc |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 05, 2006 5:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
But you can't show that runmqtmc has failed until you fix the application.
If the application abends, and you have not run the application in the background using & or "start" or etc, then runmtmc will see the non-zero return code from the application. It seems entirely reasonable to me for it to try to retrigger at that point.
If you want to determine if runmtmc itself is doing something wrong, either ensure that the application functions properly, or instruct runmtmc to start the process in the background so that it will not wait for the application to return - and thus won't receive the bad return code.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jlamond |
| Posted: Fri May 05, 2006 6:11 am Post subject: |
|
|
Voyager
Joined: 28 May 2002
Posts: 94
Location: Paris
|
I don't agree, the trigger monitor does normaly drop the trigger message in the dead letter queue when the lunched process fail... Unless IBM have change the scope of the default trigger monitor program.
Could you imagine all of a sudden nothing working in prod because of this situation. Infrastructure program should handle those situation and take the appropriate action.
_________________
Jean-Marc |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 05, 2006 8:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jlamond wrote: |
| the trigger monitor does normaly drop the trigger message in the dead letter queue when the lunched process fail... |
Nothing I've said disagrees with that.
What I said is that the trigger monitor will see the bad return code. I also said that it was reasonable for it to try and retrigger.
Really, though, it's not runmqtmc that will retrigger. It's the fact that the initial trigger conditions are still satisfied.
You can not depend on your infrastructure to protect you from every possible bad situation produced by an application. You can very easily design an MQ infrastructure that will actually cause outages - just enable linear logging, don't perform any cleanup, and use a small partition for log files.
It is entirely up to you to understand how MQ works and how to build it properly so that it supports your business requirements. It is entirely not up to IBM to build MQ so that it works out of the box perfectly for every possible situation.
All I'm really saying is - with MQ it is always the application's fault, unless you can prove otherwise. And you haven't even started trying to prove otherwise - you're just trying to blame runmqtmc.
Fix the application, first and foremost.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jlamond |
| Posted: Fri May 05, 2006 8:41 am Post subject: |
|
|
Voyager
Joined: 28 May 2002
Posts: 94
Location: Paris
|
"All I'm really saying is - with MQ it is always the application's fault, unless you can prove otherwise. And you haven't even started trying to prove otherwise - you're just trying to blame runmqtmc."
Never mind. I am just reporting what I consider a "bug"... I have been working with MQ since 1996 on MVS, Microsoft, UNIX and AS400. Many thing happen and many time I had to debug application code...
Sometime IBM does have bug in is code (no body is perfect), and this time I really feel it's the case. Just look at the number of APARs and PTFs...
Regards
_________________
Jean-Marc |
|
| Back to top |
|
|
| mvic |
| Posted: Fri May 05, 2006 8:56 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jlamond wrote: |
| I am just reporting what I consider a "bug"... |
I'm aware you may already know this, so apologies... but if you need to report a bug, then this has to be done via IBM Support. Contact details are available at http://www.ibm.com/software/integration/wmq/support/
I am not convinced the trigger monitor is defective here, but (hypothetically, theoretically) if it is defective, IBM Support will need to have a detailed report showing the problem occurring, so that analysis can be done.
Thanks for using MQ since 1996.  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 05, 2006 2:50 pm Post subject: Re: runmqtmc looping on Solaris |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jlamond wrote: |
| - runmqtmc looping for ever and core dump from the application. |
What does that mean? what is the loop? is runmqtmc trying to start new processes over and over? is it doing nothing waiting for the 1 triggered instance of the app to finish?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jlamond |
| Posted: Sat May 06, 2006 2:13 am Post subject: |
|
|
Voyager
Joined: 28 May 2002
Posts: 94
Location: Paris
|
I will investigate more next week when I have more time. I talk with the application provider (software vender). They use the trigger monitor in a real weird way - it is use only to start their application code and they don't return after 2033 ! They program had various problem with DB2 client and other libraries... It seem that they also catch 'signal'. The application code is a mixture of 'C' and MicroFocus Cobol. I have a strong feeling that the problem is releated to the signal handling from within the application code.
The loop seam to be cause by the abend which roolback the trigger message into the initq, and since the signal is intercept by the application code, the trigger monitor do not forward the trigger message in the dead letter queue.
I did not yet open a bug at IBM because after digging a bit I found out about the signal handling. This might be the cause of problem.
Will keep you posted - if ever interested.
_________________
Jean-Marc |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon May 08, 2006 2:27 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Good plan.
Very rarely have problems reported in the trigger monitor lead to an APAR, it is nearly always an error of some kind, usually to do with the trigger conditions, like Peter says.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
