| Author |
Message
|
| pshan81 |
 Posted: Thu Aug 07, 2008 1:44 am Post subject: Handling Uncommited messages in a queue |
 |
|
Acolyte
Joined: 24 May 2005
Posts: 72
|
I have a long running application that fetches messages from a local queue ( Ex:LQ1) and does some business validation.There are several external applications across countires that puts the messages into the queue(LQ1).Today I can see some uncommited messages in the queue (LQ1).Is there any way to track the application who has not commited the messages?How to handle the uncommited messages in a queue?
As the messages comes to the queue continuously from several applications,the commited messages are processed successfully by the application. |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Aug 07, 2008 2:08 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Look at queue handle status in MQExplorer. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 07, 2008 6:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| How to handle the uncommited messages in a queue? |
This is done by the application program with MQCMIT or MQBACK API calls, not by sysadmins.
The usual application behavior is to commit/backout messages associated with a business transaction - usually a short-duration event.
Take a look at the MAXUMSGS qmgr attribute. With MAXUMSGS, you can limit the number of uncommitted messages in a UofW.
Are uncommitted messages an issue for you? If so, please explain why.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| pshan81 |
| Posted: Thu Aug 07, 2008 8:46 pm Post subject: |
|
|
Acolyte
Joined: 24 May 2005
Posts: 72
|
| Uncommited messages started piling up on the queue in production.We do not know which application has not commited as there are lot of applications across countries putting the message into the queue.As part of production support,we need to inform the corresponding application team to check why the messages are not commited. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 07, 2008 11:07 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Bad programming, which should never had made it to production.
What I do is have a MQ application checklist which verifies proper MQI behaviour (such as not opening output queues for input as well). |
|
| Back to top |
|
|
| SAFraser |
| Posted: Fri Aug 08, 2008 4:13 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
What leads you to believe that the messages are uncommitted on the PUT side, rather than uncommitted by your long-running application on the GET side?
Uncommitted messages are not inherently evil. A really busy queue can show uncommitted messages nearly continuously (but each 'uncommitted' event is short).
But perhaps you are concerned because this is unusual behavior for your queue? Or perhaps you are seeing linear logs held active for a long time, or you are rolling back transactions in your circular logs?
I think none of us (so far, anyway!) have any advice to give you on determining who is the culprit. A nice design feature might have been to have the various locations deliver to their own queues, but I bet it's too late for that! |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Aug 08, 2008 12:47 pm Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| Quote: |
| Uncommited messages started piling up on the queue in production.We do not know which application has not commited as there are lot of applications across countries putting the message into the queue. |
Do you mean that the applications are connected to queue manager in clinet mode and getting/putting the messages?
If that's so, you can use this method.. now its on your luck if can find the real culprit... but if you have an idea who can be... then may be you can...
use this command :
dis qs(ur queue name) type(handle)
where 'ur queue name' is queue with uncommitted msgs.
this will give you the process name and PID (process id). now, with either's help you can find which application is connected to this queue from longest time period. that may be the culprit if the UofW is not yet completed. 
_________________
Regards
Sumit |
|
| Back to top |
|
|
| pshan81 |
| Posted: Mon Aug 11, 2008 2:54 am Post subject: |
|
|
Acolyte
Joined: 24 May 2005
Posts: 72
|
| Quote: |
Do you mean that the applications are connected to queue manager in clinet mode and getting/putting the messages?
|
The putting application is connected to the queue manager in client mode.The getting application(without syncpoint) is running on the same machine as the queue manager server.
| Quote: |
dis qs(ur queue name) type(handle)
where 'ur queue name' is queue with uncommitted msgs .this will give you the process name and PID (process id).
|
The above command is not showing the process name and process id.Please find the below output
dis qstatus(SGXXX)
5 : dis qstatus(SGXXX)
AMQ8450: Display queue status details.
QUEUE(SGXXX) IPPROCS(1)
OPPROCS(2) CURDEPTH(1)
UNCOM(YES)
dis qstatus(SGXXX) type(handle)
6 : dis qstatus(SGXXX) type(handle)
AMQ8450: Display queue status details.
QUEUE(SGXXX)
AMQ8450: Display queue status details.
QUEUE(SGXXX) |
|
| Back to top |
|
|
| ranganathan |
| Posted: Mon Aug 11, 2008 8:53 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
If you wanna know which application has put the message. Just see the message contexts 'Application' 'Put application Name' of the (MQMD) message descriptor... It will also give the user identifier..  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 11, 2008 3:12 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ranganathan wrote: |
| If you wanna know which application has put the message. Just see the message contexts 'Application' 'Put application Name' of the (MQMD) message descriptor... It will also give the user identifier.. |
That's kinda difficult to do on uncommitted messages.
You might want to read up on the dspmqtrn and rsvmqtrn commands. Maybe they will help.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| SAFraser |
| Posted: Mon Aug 11, 2008 5:53 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
You do not have to have an application running under syncpoint for uncommitted messages to exist. MQ does under-the-covers syncpoint to assure message delivery. A message is uncommitted between the time an application gets the message and then commits the get. These types of uncommitted messages are not visible is dspmqtrn.
For example, a well written application might get a message, but not commit the get until the data has been inserted into a database.
In my experience, the getting application is nearly always the culprit in uncommitted messages. That's just my experience. |
|
| Back to top |
|
|
|
|
