| Author |
Message
|
| MansaShankar |
 Posted: Mon Aug 11, 2008 7:55 am Post subject: Late processing of messages |
 |
|
Newbie
Joined: 11 Aug 2008
Posts: 4
Location: Bristol
|
Hi All,
I am facing a strange problem and am looking forward to your help in resolving this issue.
Background:
In the production MQ setup of the company I work for, webmethods puts request messages on to a local queue on my queue manager and waits for a response on a reply queue on the same queue manager. A poller application polls on the request queue and processes messages as soon as one arrives on the queue.
A wait interval of 5 secs has been set such that the poller polls on the queue every 5 seconds and checks for new messages.
When webmethods puts the request messages, it sets a timeout on the request message as 10 seconds and waits for a response for 30 seconds after which the thread times out and reports in the logs that no response came for the request.
Issue:
The issue is that webmethods has been reporting of late that they are placing messages on the request queue and not receiving response messages. i.e the webmethods thread is timing out after 30 seconds of waiting for response on response queue.
But the poller's logs are reporting that no messages were on the queue at the time that webmethods have claimed to have put the messages.
Hence according to webmethods the messages are not being picked up on time because of which the request messages are timing out in 10 seconds and the next MQGET call is removing the expired messages from the queue.
These applications have been running for ages and no configuration or code changes have been made.
I cannot start MQ tracing becuase it will impact the performance of the queue manager. My queue manager is very big and has many queues and different applications connect to it. I am also unable to deploy exits like MirrorQ because it needs a restart of the queue manager and this cannot be done with out many many approvals and will cause a major outage. Hence in the meanwhile I am trying to get different opinions.
Please let me know if setting this wait interval can cause such issues or could there be anything else that I need to check.
Thanks a lot for your help |
|
| Back to top |
|
 |
| ranganathan |
| Posted: Mon Aug 11, 2008 8:26 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
| Please check the 'Message Type', 'Reply to Queue', 'Reply to Qmgr' attributes of the message descriptor. (MQMD) and make sure that all are correct. Also make sure to check the 'Expiry' attribute is correctly set by the WebMethods. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Mon Aug 11, 2008 10:24 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
You might also try browsing (amqsbcg) the request queue when there are supposed to be messages on it. This will confirm that the request messages actually got to the other side.
Ignore this....I just read the original append a little closer and see that the messages are getting to the responder.... |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Aug 11, 2008 6:54 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Are they putting the message under syncpoint and not commiting it?
Did they change the application code?
Are the putting and getting applications locally attached?
What platform?
What software levels? |
|
| Back to top |
|
|
| MansaShankar |
| Posted: Tue Aug 12, 2008 5:20 am Post subject: |
|
|
Newbie
Joined: 11 Aug 2008
Posts: 4
Location: Bristol
|
| kevinf2349 wrote: |
Are they putting the message under syncpoint and not commiting it?
Did they change the application code?
Are the putting and getting applications locally attached?
What platform?
What software levels? |
Hi All,
Thanks for replying.
They are committing the messages and the application code has not be changed. They put the messages on to the queue using a client connection channel and the application that picks and processes these messages is present on the same machine as the queue manager.
The queue manager is on HPUX 11.11 and the MQ version is 5.3
Thanks |
|
| Back to top |
|
|
| MansaShankar |
| Posted: Tue Aug 12, 2008 5:21 am Post subject: Late processing of messages |
|
|
Newbie
Joined: 11 Aug 2008
Posts: 4
Location: Bristol
|
Also i cannot browse the queue becuase the application that picks from the queue is so fast that the messages are never there for browsing.
I have tried doing this before |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Tue Aug 12, 2008 5:59 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
How about changing the putQ/Request Q name from the application side, to a TESTQ; if it is a client. Or if it is a fat client having a Qmgr of its own then definately an aliasQ/RemoteQ would be pointing to you localQ. Alter the definations to get the message to a testQ.
Ahh.. think this will be pretty complicated for u to understand.. just forget it..
Second could be to get disable the Q and see if the connected application goes down. And then, viola.. u have ur message.
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 12, 2008 9:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Looks again like the app is expecting the reply within the same UOW as where the put happened? Did somebody redeploy the app and changed the deployment descriptor for transactionality?
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dkeister |
| Posted: Tue Aug 12, 2008 9:52 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
Have you checked dead letter and/or back-out queues?
_________________
Dean Keister |
|
| Back to top |
|
|
| MansaShankar |
| Posted: Wed Aug 13, 2008 1:24 am Post subject: |
|
|
Newbie
Joined: 11 Aug 2008
Posts: 4
Location: Bristol
|
I dont see messages going into the dead letter queue. I feel triggering an application to just make a note of the time when a message has arrived is the only solution to keep track of when messages arrive at the queue.
Please could anyone let me know if putting a trigger on a queue impacts performance in anyway? Also I would like to know your thoughts on using triggers or if there is anything else that I could do.
Thanks |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 13, 2008 5:02 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MansaShankar wrote: |
| Please could anyone let me know if putting a trigger on a queue impacts performance in anyway? |
Yes.
One of the apps is likely not logging everything it should, or app support is not 100% forthcoming. There is a critical detail or two missing.
Use your MQ monitoring software to track messages counts thru these queues to help ID where the breakdown is.
It could be something silly as the app that's waiting for the reply is specifying the wrong match options for some reason.
Up that Expiry time! I hate apps that put tiny Expiry times - it makes it impossible to track where the messages are when there is a problem if they are dissappearing almost immediatly! Upping the Expiry time should be a easy and safe thing to do to help solve this IF you have no other tracking options - monitoring software like QPASA and QNAMI, traces and/or MQ API exits like Transaction Vision.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
