Author |
Message
|
kannurkiran |
Posted: Tue Dec 11, 2007 11:07 pm Post subject: Queue depth in INITQ increasing. |
|
|
Newbie
Joined: 11 Oct 2007 Posts: 7
|
Hi,
I have an application that should be triggered when a message arrives on the a queue. to achieve this this queue has a initq and a process associated and the INITQ is controlled by a trigger monitor.
the trigger monitor is always on.
The application is designed such that when its triggered the queue which triggers it is drained (completely).
the problem here is that, with the queue being drained the depth of the INITQ starts increasing, and once the application exits (the exit condition being a 2033 being returned from the queue) the application is re-triggered due to presence of the messages in INITQ(retriggered sequentially as many times as the number of messages here).
The triggering condition is being set to First, and hence the problem above seems slightly over the head, atleast to a novice like me.. Is there a way to control the messages coming to INITQ?
Also the INITq depth when set to 1 generates event log warnings - which is yet another problem.. :(
:help: |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 12, 2007 1:45 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
It sounds a lot like the trigger condition is set to every not first; this is causing the queue manager to send messages to the initq for each message in the target queue.
I'd also check that nothing else is using the same initq for a different process and you're getting different trigger messages. Does your triggered application use the trigger header to determine target queue or does it assume it? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
atheek |
Posted: Wed Dec 12, 2007 2:13 am Post subject: |
|
|
 Partisan
Joined: 01 Jun 2006 Posts: 327 Location: Sydney
|
You have mentioned that your application exits after reading all the messages from the queue. Are you reading all the messages within the same
MQOpen..or are you issuing a mqclose in each iteration..and finally when you get a 2033 , do mqdisc and exit?? The queue manager issues a new trigger messages if it finds that there is atleast one message in the queue and no application is processing it..so whenever IPPROCS becomes 0 it issues a new trigger message...quite possible if you are using MQCLOSE within an iteration
-Atheek |
|
Back to top |
|
 |
kannurkiran |
Posted: Wed Dec 12, 2007 4:34 am Post subject: |
|
|
Newbie
Joined: 11 Oct 2007 Posts: 7
|
Perfect analysis atheek..
Thanks a ton.. the issue was the same as you have mentioned. i was doing a disconnect after each call...  |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 12, 2007 4:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
kannurkiran wrote: |
Perfect analysis atheek.. |
Nice.....
kannurkiran wrote: |
i was doing a disconnect after each call... |
As a general programming point this is a bad practice even for a non-triggered application. Connection is an expensive opperation and even though (as you've discovered) it's perfectly valid to connect/disconnect you'll pay dearly in terms of performance.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
kannurkiran |
Posted: Wed Dec 12, 2007 5:35 am Post subject: |
|
|
Newbie
Joined: 11 Oct 2007 Posts: 7
|
point noted... Thanks a lot.. :D |
|
Back to top |
|
 |
|