| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Resource contention in API |
« View previous topic :: View next topic » |
| Author |
Message
|
| tso0rxp |
 Posted: Wed Aug 14, 2002 3:56 am Post subject: Resource contention in API |
 |
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
Environment: MQ v5.2 (upgraded past Sunday from 5.0). Solaris v2.6. Mercator 5.0 with MQ Adapters. Multiple (20+) applications set up with triggering (every). Since the upgrade, 1 particular interface that triggers a script to run Mercator is failing with 'target not available' - target being the queue manager. It does not happen on all messages, though. Only 2 or 3 of them are failing out of 15. Other apps with triggering are running near the same time OK and the queue manager is available.
Things i've noticed... memory on server low at the time but not critically low. Three trigger monitors are running servicing all applications (started using runmqtrm). Never had this happen under v5.0. No FDC files generated. No other messages from MQ Series in the error directories. Server was not recycled after upgrade. 
When triggered application fails a message is put to SYSTEM.DEAD.LETTER.QUEUE and the contents are
Dead Letter Header:
Reason = 265 (Appl Cannot Be Started)
Dest. Queue = QI.LOW
Dest. QMgr = MERP
ApplName = RUNMQTRM
Put Date = 20020814
Put Time = 07592658
**************************************************************************
Application data, however, stays in the application queue set up as triggered every. I then manually run the 'triggered' script to push the data through.
Hopefully, the board will ask additional info. and/or suggestions for resolution. This problem is waking me up at 2:30am the last 3 mornings so I'm anxiously awaiting advice! |
|
| Back to top |
|
 |
| bduncan |
| Posted: Wed Aug 14, 2002 6:32 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
A couple questions:
1) Why do you have 3 trigger monitors running? If you are only using a single initiation queue, then definitely, you should only be using one trigger monitor. If you have 3 initiation queues, perhaps you should consider consolidating it down to one.
2) Have you tried running the trigger monitor(s) in the foreground? Typically the trigger monitor will send a more verbose explanation to stdout when it fails to trigger an application.
3) Since you are triggering different applications, it sounds like the messages you are triggering off of are of different types, i.e., their contents differ in some way which requires different applications to process them. You mentioned that the problem "does not happen on all messages" - have you noticed if the problem occurs only on certain types of messages? Or messages bound for a particular application?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Wed Aug 14, 2002 9:16 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
We have 3 trigger monitors running because of the volume of IDOC's that come from our SAP system and the amount of time it takes to process each IDOC. If we didn't do this we would never complete the batch cycles in time for the next day's business. We don't trigger background tasks, either, so each message must be fully processed before another is released from the initiator.
Yes, I've tried running the monitors in the foreground. I never really noticed what additional info is available to stdout. Maybe I'll do that tonight. Thanks.
The type of message may have something to do with this - because certain message types from SAP are processed by certain Mercator maps within our system.
Thanks for the ideas. |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Thu Aug 15, 2002 6:53 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
I took this interface and single threaded the messages thru 1 trigger monitor and it ran successfully.
Unfortunately, I can't do this to the other interfaces that are failing. I had another go down last night because the triggered process could not receive the message from the QMGR. I sporatically received message 'could not connect to qmgr'. Strange thing was that while the interface was running I was on another terminal issuing 'runmqsc' commands to monitor the queue depth. Periodically, my runmqsc command would fail because it could not connect to the qmgr. Then, a few seconds later I would enter the same command and see the depth of all the queues.
Strange indeed. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu Aug 15, 2002 7:21 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
I know this is reaching but can you try bumping up the max handles
runmqsc
alt qmgr maxhands(1024)
I tried it on NT it appears to take affect without a restart.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Thu Aug 15, 2002 7:30 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
I will try this.
Before I do it, however, I stumbled on to something.
I ran the application again and was able to make it fail each time. This allowed me to tweak some things in the application script that is triggered. One thing the developers do in their scripts is test for qmgr availability by writing a dummy message to a generic queue and then delete the message before the actual application queues are read.
I commented out this extraneous code and the application that was failing suddenly does not fail.
One other common thread to the failing applications is the error 'qmgr not available' was only occurring for the the Mercator maps that dump the data to a file (vs. a remote or local queue). I'm not sure what the relationship is to the error I'm having, though.
If I continue to get failures, I'll try your suggestion on maxhands. |
|
| 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
|
|
|
|
