| Author |
Message
|
| thomas3557 |
 Posted: Wed Oct 06, 2004 6:40 am Post subject: Deleting uncommitted messages |
 |
|
Novice
Joined: 25 Feb 2002
Posts: 12
Location: Ohio
|
We have an application using JMS that is crashing before committing a message. Is there a way to delete uncommitted messages, or delete a queue that contains uncommited messages. I'm getting AMQ4045 when attempting to delete through Windows MMC, and an AMQ8143 when trying to delete the queue in runmqsc.
Thanks |
|
| Back to top |
|
 |
| csmith28 |
| Posted: Wed Oct 06, 2004 6:58 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
try
clear ql(QUEUE.NAME)
Note this will not work if the QUEUE is busy, if so try stoping all the applications and channels that may have a hold on the Queue and try to clear it again.
Or try using the sample script "amqsget QLOCAL.NAME MQMGRNAME". amqsget will fail if the messages are larger than 200 bytes.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| thomas3557 |
| Posted: Wed Oct 06, 2004 7:16 am Post subject: |
|
|
Novice
Joined: 25 Feb 2002
Posts: 12
Location: Ohio
|
| Thanks for the reply. I tried both methods but it is still not removing the uncommitted message. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Wed Oct 06, 2004 7:23 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Does the QUEUE show a depth?
Is this a normal QLocal or a Transmit Q?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| thomas3557 |
| Posted: Wed Oct 06, 2004 7:33 am Post subject: |
|
|
Novice
Joined: 25 Feb 2002
Posts: 12
Location: Ohio
|
| Yes, the queue shows a depth, however, if you use the windows mmc utility to view the message, you won't be able to see it. This is a local queue. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Wed Oct 06, 2004 7:49 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| thomas3557 wrote: |
| Yes, the queue shows a depth, however, if you use the windows mmc utility to view the message, you won't be able to see it. This is a local queue. |
Did you try stopping the SVRCONN Channels or the application that is supposed to GET the messages?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| thomas3557 |
| Posted: Wed Oct 06, 2004 8:46 am Post subject: |
|
|
Novice
Joined: 25 Feb 2002
Posts: 12
Location: Ohio
|
| Yes, tried both of those. The only fix I have at this point is to restart the qmgr. |
|
| Back to top |
|
|
| vennela |
| Posted: Wed Oct 06, 2004 8:54 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
Have you tried rsvmqtrn?
Is there a process that is keeping the queue open? You can find this out using the qstatus |
|
| Back to top |
|
|
| JT |
| Posted: Wed Oct 06, 2004 9:01 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| The RFHUTIL utility found in the IH03 supportpac allows you to remove messages (purge) from a queue even if there are open handles. |
|
| Back to top |
|
|
| thomas3557 |
| Posted: Wed Oct 06, 2004 9:32 am Post subject: |
|
|
Novice
Joined: 25 Feb 2002
Posts: 12
Location: Ohio
|
You guys are all giving me some great options here, but I still can't clear that uncommitted message. Qstatus shows no open handles to the queue. Qstatus also shows a queue depth of 1, yet the RFHUTIL does not see any messages in the queue, kind of like the Microsoft mmc:
AMQ8450: Display queue status details.
QUEUE(IMG.BREP.QUEUE3) IPPROCS(1)
OPPROCS(0) CURDEPTH(1)
UNCOM(YES)
I also ran rsvmqtrn, but that didn't clear it either:
C:\TOOLS>rsvmqtrn -m QMGR -a
Any in-doubt transactions have been resolved. |
|
| Back to top |
|
|
| frankdk |
| Posted: Wed Oct 06, 2004 10:25 am Post subject: |
|
|
Novice
Joined: 10 Jun 2004
Posts: 20
Location: Copenhagen, Denmark
|
Just a hint, maybe not the solution:
You should have a live unit of work(UOW).
If you do this:
MQCONN
MQOPEN
MQPUT
MQCLOSE
and then wait for whatever you will end up with uncommited message(s) and no handles on the queue.
_________________
Regards,
Frank |
|
| Back to top |
|
|
| Heinz57 |
| Posted: Wed Oct 06, 2004 12:21 pm Post subject: |
|
|
Apprentice
Joined: 21 Jan 2004
Posts: 26
Location: Syracuse, NY
|
| We've never been able to clear an uncommitted message without recycling the qmgr. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Oct 06, 2004 1:56 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
What does dspmqtrn (try -i and -e) show? Although, I imagine they don't show anything based on rsvmqtrn resolving things.
However, the last time I ran into this, shutting the qmgr down didn't resolve it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 06, 2004 3:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
We have a java application and had the same problem with uncommited messages in the transmission queue.
We did not look at the transaction utilities (my fault) but just bouncing the qmgr got rid of them.
What your team really needs to find out is why the app dies before being able to do the rollback. My guess is it does not handle MQ resource release correctly in any case and you would have problems down the road with it.
Enjoy  |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Oct 07, 2004 12:21 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The UoW should be rolled back when the app ends. I guess that since this is a JMS app that the PID of the connected process, which is what the agent is looking at, is the PID of the JVM. This means that the agent thinks that the process is still running, ad so does not roll back the UoW.
The msg will be removed when the qmgr ends, because the agent will forcibly break the connection and end the UoW then
Try ending all your JMS.Java apps, so that there is no 'java' process running, The agent should then recognise that the app has ended and roll back the UoW on behalf of the crashed app. |
|
| Back to top |
|
|
|
|
