| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Will CONN UOWSTATE change from time to time? |
« View previous topic :: View next topic » |
| Author |
Message
|
| issac |
 Posted: Fri Aug 03, 2012 5:20 am Post subject: Will CONN UOWSTATE change from time to time? |
 |
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hello, in our production environment, I see a CONN showing UOWSTDA, UOWSTTI beginning from quite an early time, and its UOWSTATE is ACTIVE.
Does this indicate this CONN for sure is doing something very very slowly and could cause relevant applications (like the WAS which accesses the QMGR) to run slowly?
I read this in the InfoCenter:
| Code: |
Then issue the following command, inserting in <appltag> the APPLTAG value from the output of the previous command:
DISPLAY CONN(*) WHERE(APPLTAG EQ <appltag>) UOWSTDA UOWSTTI
This shows when the unit of work was started and will help you discover whether the application is creating a long running unit of work. If the putting application is a channel, you might want to investigate why a batch is taking a long time to complete. |
I'm not sure about the answer, because I'm afraid UOWSTATE of the CONN is changing from NONE to ACTIVE ... then to NONE to ACTIVE back and again.
Perhpas it has served a previous request to PUT/GET some messages, and then the UOWSTATE went to NONE. The moment I see the CONN it happens to be working so the UOWSTATE is ACTIVE and UOWSTDA UOWSTTI are from long ago. So it appears to be working for long but actually it has been working fast and does not indicate any performance problem.
 Hopefully I've made myself clear...
Then another question, I've just found restarting the QMGR would not reset UOWSTDA and UOWSTTI for a CONN. Why? All my applications have for sure been disconnected when I recycle the QMGR, why does their CONN persist?
_________________
Bazinga! |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Aug 03, 2012 5:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's more likely that the application does not close (commit) the UoW in a timely manner.
Nothing in the QM takes that long to complete.
It's possible to have UNCOM yes on a queue that has no application accessing it - at least I have seen it happen.
There are special MQ commands for displaying (dspmqtrn) and resolving open transactions (rsvmqtrn), but these should be used with caution. rsvmqtrn has a bad bug before MQ v7016 which actually makes matters worse!
Probably a good idea to open a PMR - but watch out for that command problem - it was IBM support center who mentioned it to me and then told me (later) that it had a bug!
IZ96934: RSVMQTRN CAUSES QUEUE MANAGER AGENT TO FAIL WITH XC130003 FDC, OTHER APPLICATIONS CAN ALSO FAIL |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 04, 2012 6:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
| It's more likely that the application does not close (commit) the UoW in a timely manner. |
Or the TM transaction times out before it can ever get to a XA_prepare_commit ...
Could be typicall in a J2EE environment where the transactional behavior of the app was completely left to the container and nobody thought about minimizing transactional time at development... and of course a result of poor coding practices...
| zpat wrote: |
Nothing in the QM takes that long to complete.
It's possible to have UNCOM yes on a queue that has no application accessing it - at least I have seen it happen.
There are special MQ commands for displaying (dspmqtrn) and resolving open transactions (rsvmqtrn), but these should be used with caution. rsvmqtrn has a bad bug before MQ v7016 which actually makes matters worse! |
I don't believe that these (dspmqtrn) will show an XA transaction that has been started but never received the XA_prepare_commit....
| zpat wrote: |
Probably a good idea to open a PMR - but watch out for that command problem - it was IBM support center who mentioned it to me and then told me (later) that it had a bug!
IZ96934: RSVMQTRN CAUSES QUEUE MANAGER AGENT TO FAIL WITH XC130003 FDC, OTHER APPLICATIONS CAN ALSO FAIL |
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
