| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ trigger going to sleep. |
« View previous topic :: View next topic » |
| Author |
Message
|
| camvdcs |
 Posted: Mon Jun 16, 2003 9:52 am Post subject: MQ trigger going to sleep. |
 |
|
Newbie
Joined: 16 Jun 2003
Posts: 6
|
Hi MQ guru's. We have MQ Ver 1.2 (currently migrating to 5.3.1) running on OS/390. There is a QMGR that runs on an LPAR along with a CICS application that issues PUTS and GETS. We use the trigger method 'FIRST' on all the queues. During the course of the day (8 to 5) we get a lot of messages flowing via MQ. Once or twice a day, the trigger is delayed 20 - 50 seconds from starting. This seems to affect all MQ triggers to CICS. After the delay, the CICS trans start for the various queues and they are all drained. Other CICS transactions run normal during this time.
Is this a capacity problem? Workload Manager problem (WLM)? Is this a case of the MQ TCB in CICS competing with the QR TCB in CICS? Will converting the program in CICS to a semi-long running program rectify the problem?  |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Jun 16, 2003 4:08 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I'm not a CICS or mainframe expert, but I'm curious: when you say the trigger is delayed, I'm guessing you are seeing the queue depth go from 0 to 1, and some time passes before the application actually starts. During this interval, have you ever witnessed the queue depth go from 1 to 2 (or more)? Because presumeably if the trigger monitor is tied up or hung temporarily, when it finally came to and saw the queue depth >1, it would NOT trigger your application because trigger type first means "only trigger when the queue depth goes from 0 to 1" not 1 to 2, etc... So if it was something wrong with the trigger monitor, I'd expect that sometimes you'd see the trigger not happen and then the queue just start filling up until you start your application by hand. Otherwise, I'd look to see if the depth on the initiation queue is ever nonzero. This would mean that the queue manager is immediately putting the trigger message on the initiation queue, but something is preventing the trigger monitor from getting it right away and acting on it. Otherwise, if you never see the depth on the initiation queue nonzero, it means that the trigger monitor is getting the trigger message right away, but is getting delayed in actually starting your application (which would indicate heavy cpu usage, I/O bottleneck, etc)...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| camvdcs |
| Posted: Tue Jun 17, 2003 8:09 am Post subject: |
|
|
Newbie
Joined: 16 Jun 2003
Posts: 6
|
Thanks for responding bduncan.  When the scenario occurs, we don't manually start the CICS task. When the task does start, it processes a number of transactions depending on how long the delay was. I'm not the CICS programmer that uses the MQ API but I am looking at the problem. We have no monitoring tool to look at our MQ managers. If we did, we might be able to see a little more detail. I can only make assumptions here. If we use trigger on 'FIRST', the MQ trigger will start the CICS task only when the queue went from 0 to 1. It will not trigger otherwise. Since nobody manually started the CICS task, I assume that triggering the task is hung up in either MQ or CICS.
What is your take on converting it to a long running or semi-long running task? I know that our DATA CENTER will complain that they cannot monitor the performance of long running task. |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jun 17, 2003 12:04 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well, I'd stay away from writing an application that runs forever polling the queue for messages and processing them. From time to time, things can occur which cause the application to get disconnected from the queue manager or crash, and until a human intervenes, messages will just pile up. The delays you are seeing are not some performance degradation inherent in triggering; normally triggering produces no noticeable lag time between a message landing on the queue and the application getting started. Of course you have the overhead of the app starting and connecting to the queue manager, but most triggered applications don't just process one message and go away. They process messages for some time until the queue is empty for a specific amount of time, and then they go away. If you've tweaked all your time intervals correctly, you can effectively cancel out this startup overhead.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Glen Shubert |
| Posted: Tue Jun 17, 2003 12:19 pm Post subject: |
|
|
Apprentice
Joined: 16 May 2001
Posts: 42
Location: TSYS - Columbus, GA
|
We have seen this issue with non-committed messages. The trigger takes place before the message is committed and available. We set our Trigint to 120000 to redrive the trigger to get around this.
_________________
Glen Shubert
Associate Director
MQSeries Technical Support
TSYS |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
