| Author |
Message
|
| guest468 |
 Posted: Wed May 27, 2009 8:53 am Post subject: uncomited message on the queue |
 |
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
Hi,
I am seeing UNCOM(YES) for a broker input queue. The concerned broker flow is in stopped state and there are no connections(IP or OP) on that queue.
1 : dis qs(TESTQ) all
AMQ8450: Display queue status details.
QUEUE(TESTQ) TYPE(QUEUE)
CURDEPTH(2) IPPROCS(0)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MONQ(OFF) MSGAGE( )
OPPROCS(0) QTIME( , )
UNCOM(YES)
Queue doesnot have any messages from MQGET point of view.
Any idea?
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed May 27, 2009 9:09 am Post subject: Re: uncomited message on the queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| guest468 wrote: |
| Queue doesnot have any messages from MQGET point of view. |
It wouldn't - uncomitted messages are not eligible to be retrieved.
Proceed as you would for uncommitted messages on any queue - the fact that this is being served by broker affects nothing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| guest468 |
| Posted: Wed May 27, 2009 10:01 am Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
Vitor,
Actually I was trying to understand who is holding those uncommited messages. The queue has no i/p or o/p connections
Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 27, 2009 10:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| guest468 wrote: |
| Actually I was trying to understand who is holding those uncommited messages. |
Whatever was putting the messages has stopped (probably abended) without committing them. Nothing is "holding" them, hence the lack of queue handles.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| guest468 |
| Posted: Wed May 27, 2009 10:53 am Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
I thought MQ will backout the message once the app which is holding it goes down or looses connection.
And is there anyway to clear these uncommitted messages? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 27, 2009 12:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| guest468 wrote: |
| I thought MQ will backout the message once the app which is holding it goes down or looses connection. |
How would the queue manager detect the app going down? You'll find enough discussions in here about apps not closing connections properly.
| guest468 wrote: |
| And is there anyway to clear these uncommitted messages? |
Look up the rsvmqtrn command.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| guest468 |
| Posted: Wed May 27, 2009 12:41 pm Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
The connection on the queue is lost when app goes down. I thought it(loosin connection) is part of the synpoint coordination.
And in my case it is locally coordinated transaction so dspmqtrn is not showing anything. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 27, 2009 1:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| guest468 wrote: |
| The connection on the queue is lost when app goes down. |
The connection isn't to the queue, it's to the queue manager.
| guest468 wrote: |
| I thought it(loosin connection) is part of the synpoint coordination. |
No.
| guest468 wrote: |
| And in my case it is locally coordinated transaction so dspmqtrn is not showing anything. |
That command should still work though to clear the messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 27, 2009 4:44 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| guest468 wrote: |
| I thought it(loosin connection) is part of the synpoint coordination. |
No.
|
I think yes.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzak.doc/csqzak10306.htm
| Quote: |
If the application issuing the MQGET call is running as an MQ client, the message retrieved can be lost if, while processing the MQGET call, the MQ client terminates abnormally or the client connection is severed. This arises because the surrogate that is running on the queue-manager's platform and that issues the MQGET call on the client's behalf cannot detect the loss of the client until the surrogate is about to return the message to the client; this is after the message has been removed from the queue. This can occur for both persistent messages and nonpersistent messages.
To eliminate the risk of losing messages in this way, always retrieve messages within units of work (that is, by specifying the MQGMO_SYNCPOINT option on the MQGET call, and using the MQCMIT or MQBACK calls to commit or back out the unit of work when message processing is complete). If MQGMO_SYNCPOINT is specified, and the client terminates abnormally or the connection is severed, the surrogate backs out the unit of work on the queue manager and the message is reinstated on the queue.
In principle, the same situation can arise with applications that are running on the queue-manager's platform, but in this case the window during which a message can be lost is very small. However, as with MQ clients, you can eliminate the risk by retrieving the message within a unit of work.
|
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzak.doc/discuse.htm
| Quote: |
If the application ends with uncommitted changes in a unit of work, the disposition of those changes depends on how the application ends:
A. If the application issues the MQDISC call before ending:
For a queue-manager-coordinated unit of work, the queue manager issues the MQCMIT call on behalf of the application. The unit of work is committed if possible, and backed out if not.
On z/OS, batch programs (including IMS(TM) batch DL/1 programs) are like this.
For an externally-coordinated unit of work, there is no change in the status of the unit of work; however, the queue manager typically indicates that the unit of work must be committed when asked by the unit-of-work coordinator.
On z/OS, CICS, IMS (other than batch DL/1 programs), and RRS applications are like this.
B. If the application ends normally but without issuing the MQDISC call, the action taken depends on the environment:
On z/OS, the actions described under (a) above occur.
In all other cases, the actions described under (c) below occur.
Because of the differences between environments, ensure that applications that you want to port commit or back out the unit of work before they end.
C. If the application ends abnormally without issuing the MQDISC call, the unit of work is backed out.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 27, 2009 6:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter,
what happens in case D:
The application ends abnormally (killed -9) and the qmgr is not aware that the application terminated?
case E:
The application thread terminates abnormally (thread death), the application itself keeps running (WAS) and the qmgr is not aware of anything amiss.
(You have a long running transaction...)?
The unit of work is in flux...
Check one of the settings of dspmqtrn (-a?) to make sure whether or not it can be seen...
Wouldn't know what else to check for?
It sure looks like the message would be backed out when you bounce the qmgr... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 27, 2009 6:41 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
CURDEPTH(2)
...
UNCOM(YES)
|
We had a discussion here recently about CURDEPTH excluding msgs in UofWs due to WMQs optimism about successful delivery, and how the queue can exceed MAXDEPTH, and some other interesting stuff.
Thus CURDEPTH is a calculated value.
_________________
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 |
|
|
| Vitor |
| Posted: Thu May 28, 2009 12:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| It sure looks like the message would be backed out when you bounce the qmgr... |
This of course is the other way of removing uncommitted messages. I was suggesting something less intrusive, but this would (should) work too.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 28, 2009 3:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Peter,
what happens in case D:
The application ends abnormally (killed -9) and the qmgr is not aware that the application terminated?
case E:
The application thread terminates abnormally (thread death), the application itself keeps running (WAS) and the qmgr is not aware of anything amiss.
|
I think D and E are just variations of C, no? You have experienced D and /or E and found the UOW left hanging?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 28, 2009 7:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
Peter,
what happens in case D:
The application ends abnormally (killed -9) and the qmgr is not aware that the application terminated?
case E:
The application thread terminates abnormally (thread death), the application itself keeps running (WAS) and the qmgr is not aware of anything amiss.
|
I think D and E are just variations of C, no? You have experienced D and /or E and found the UOW left hanging? |
Yes I did. Try working with an antiquated version of ATG (thankfully it was retired back when...) which had an "unsupported" XA transaction coordinator that left messages hanging with an XA proto FDC...
We had messages in an uncommitted state as follows
- messages that had been put, but had never been requested to perform an XA prepare for commit or an XA rollback ==> ghost messages counting for the queue depth but invisible to dsmpqtrn and not in a gettable state. They will disappear when you bounce the qmgr (getting rolled back at that time?)
- messages that had been put and on which a XA prepare for commit had been called and the transaction mysteriously died. ==> those message could be resolved using dspmqtrn / rsvmqtrn. But we had to check with the source system once we committed them whether they could go on or should be deleted (duplicates)... As they were persistent these messages would survive a qmgr restart...
Now imagine the nightmare of resolving those transactions every week... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 29, 2009 1:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
External transaction coordinators....don't have to much expirience with them. But, could it be that in your cases while the app may have died, it didn't matter because the XA coordinator was still up? And as far as the sections of the Info Center I referenced, that was neither A, B or C - the "application" in this case is the XA coordinator and not THE application. And since the XA coordinator is still up, and hasn't committed or backed out, that's why the UOW state is in limbo?
Using single phase commits (no XA), I think it becomes more cut and dried and the possability of ghost UOW goes away if the application really does end, cleanly or not. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
