| Author |
Message
|
| thomas3557 |
 Posted: Thu Oct 07, 2004 6:15 am Post subject: |
 |
|
Novice
Joined: 25 Feb 2002
Posts: 12
Location: Ohio
|
I tried running dspmqtrn (both -i and -e) and there are no prepared transactions.
Also, I don't think it's the JVM holding the connection open. We have rebooted the servers running JMS and still have the rogue message out there.
Thanks |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Oct 07, 2004 7:53 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Oct 07, 2004 11:41 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| dspmqtrn only shows trans associated with extrernal resource managers, i.e. trans where WMQ is the TM with external RM, or where WMQ is a RM coordnated by an external TM. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Oct 08, 2004 2:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
We are using MQ 5.3 CSD07 on Sun Solaris and I know now what creates the ghost messages. However they disappear when we bounce the qmgr.
Ghost messages are in this case uncommitted messages. For us they happen to sit on the xmitq.
Here is the scenario that creates them:
We are running ATG. The ATG apps server is doing a 2 phase commit with JMS. For whatever reason a exception is thrown (not MQ) and before the commit/rollback is being done an additional null pointer exception is being thrown that is not being caught. So the thread either dies or exits the method without finishing the rollback.
On the rollback the datasource representing MQ has already been delisted from the transaction (MQ would be successful). The message is in an ungettable state in the xmitq and disappears when the qmgr is being bounced.
dspmqtrn does not show any transaction in progress.
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 08, 2004 3:22 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The odd thing in my case was the ghost messages were on our MQ Hub Queue Manager. There were no apps connecting to that QM. It was only the channels doing gets and puts.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Oct 08, 2004 4:31 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| PeterPotkay wrote: |
| The odd thing in my case was the ghost messages were on our MQ Hub Queue Manager. There were no apps connecting to that QM. It was only the channels doing gets and puts. |
What about poltergiest messages? 
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 09, 2004 3:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| The odd thing in my case was the ghost messages were on our MQ Hub Queue Manager. There were no apps connecting to that QM. It was only the channels doing gets and puts. |
Peter did by any chance the source qmgr/channel go down before the channel had committed the messages ?
In this case you might have had either indoubt or retrying channels.
I do not know if your messages were like ours uncommitted. We had the additional problem that the XAdatasource representing MQ had already been delisted from the transaction manager. This is the ATG transaction manager and although it will allow a 2 phase commit it is not fully J2EE compliant. So no way of finally committing or rolling back.
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Oct 09, 2004 4:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The appeared in the middle of the day, with no other problems. IBM confirmed it was a bug, and sent patched dlls to fix it. No problems since. The problem was on Windows 2000 MQ 5.3 CSD04.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Tue Nov 02, 2004 5:29 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
We had this problem yesterday. We had an app putting about 50,000 msgs from a client to AIX QMgr 5.3. Due to a shortage of dasd I limit uncommitted msgs to 20,000. When the app got the 2042, it abended and the uncommitted msgs on the SYSTEM.CLUSTER.TRANSMIT.QUEUE did not roll back. I increased the uncommitted limit to 100,000 and had them resubmit. It ran horribly slow!!
Last night we were up to 53,000 ....45,000 were either expired, non persistant or uncommitted and some messages were trickling through.
I recycled the queue manager and this resolved the issue. I had 8,000 messages when we came up and they were sent in a matter of seconds. I could not delete them otherwise.We also noticed that amqzlaa0 was using about 90% of the CPU.
I have a few questions for you folks:
1. Why would it run so slow? Does it browse through the entire queue on each get?
2. Is there any way I could have deleted them from the SYSTEM.CLUSTER.TRANSMIT.QUEUE?
TIA,
Gina
_________________
Regards,
Gina
IBM Certified MQSeries Specialist |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 02, 2004 9:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
1. Why would it run so slow? Does it browse through the entire queue on each get?
|
Because one cluster transmit queue serves a QM, and that QM may have 1, 2, dozens or thousands of Automatic Cluster Senders all reading from that same cluster transmit queue, they each need to identify which message is for which channel. I believe the way this happens is the MCA's look at the CorrelID of the message as it sits in the XMITQ. This CorrelID is from the transmit header, and not the original MQMD, and it contains a value that IDs the destination QM. So yes, the channels are browsing the S.C.T.Q. I am 99.9% sure of this. Nigel or Brandon, please correc tme if I am wrong.
| Quote: |
2. Is there any way I could have deleted them from the SYSTEM.CLUSTER.TRANSMIT.QUEUE?
|
This post has listed every idea I came up with to accomplish this, none of which work if you have the bug, short of bouncing the QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Tue Nov 02, 2004 1:03 pm Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
But it shouldn't browse the uncommitted messages...right? In which case there was only 8,000 msgs to be gotten.
Unless the MCA is looking at every single message to figure out 1. if it is 'gettable' and 2. where to put it if it is.
_________________
Regards,
Gina
IBM Certified MQSeries Specialist |
|
| Back to top |
|
|
| desjardins |
| Posted: Fri Dec 02, 2005 11:46 am Post subject: |
|
|
Newbie
Joined: 02 Dec 2005
Posts: 1
|
I ran into the same issue and was finally able to resolve it by doing:
dspmqtrn -m <MY_Q_MGR>
This gave me a Transaction,Number which I could pass to:
rsvmqtrn -m <MY_Q_MGR> -b <Transaction,Number> |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 02, 2005 11:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| desjardins wrote: |
I ran into the same issue and was finally able to resolve it by doing:
dspmqtrn -m <MY_Q_MGR>
This gave me a Transaction,Number which I could pass to:
rsvmqtrn -m <MY_Q_MGR> -b <Transaction,Number> |
But how did you know that you have taken the appropriate action (force rollback /vs force commit ?)
We arrange for the queue to be "Empty" and force commit. The apps folks are looking at the message content and decide wether to leave the message or have it deleted.
Enjoy  |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Dec 03, 2005 4:57 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| fjb_saper wrote: |
| We arrange for the queue to be "Empty" and force commit. The apps folks are looking at the message content and decide wether to leave the message or have it deleted. |
Why content? Why not according to msgId? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 03, 2005 11:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hopsala wrote: |
| fjb_saper wrote: |
| We arrange for the queue to be "Empty" and force commit. The apps folks are looking at the message content and decide wether to leave the message or have it deleted. |
Why content? Why not according to msgId? |
Answer: Because there is no guarantee that the ATG message sink did not roll back and deliver the message on a subsequent transaction.... it's all coming back to the bug in the ATG XA transaction manager....
Enjoy |
|
| Back to top |
|
|
|
|
