| Author |
Message
|
| KoGor |
 Posted: Fri Feb 12, 2010 6:39 am Post subject: Handling messages after a transaction has been broken |
 |
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
Hi All!
I have faced with a problem described below. I'm writing an application for Windows 2003 which uses MQ(6.0.2.5) Client to connect to MQ manager. I'm setting the flag MQPMO_SYNCPOINT when putting a message into local queue. In case I have put a several messages in MGR local queue and then the connection between MQ MGR and my application has been broken up before MQCMIT or MQBACK issued, these messages are leaving in a queue. They disappear only when the MQ Mgr is restarted. This is not suitable for production system when you can not restart MQ MGR for such reason. Is this normal behavior for such messages? Can be these messages deleted automatically from MQ Mgr?
Thank you in advance! |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Feb 12, 2010 6:42 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Are those messages showing as contributing to depth but unavailable for browse/get, or as depth and available?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 12, 2010 7:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Non-persistent messages are discarded from queues at qmgr restart. Is you application creating non-persistent messages? Or persistent messages?
_________________
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 |
|
|
| KoGor |
| Posted: Fri Feb 12, 2010 7:17 am Post subject: |
|
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
| They are not available for browse/get and only shown in depth field. And all messages are persistent. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 12, 2010 7:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| They are not available for browse/get and only shown in depth field. |
By not allowed, are you saying that you receive a 2035 NOT_AUTHORIZED when trying to browse the queue? Or that when you try to browse the queue, you get a 2033 NO_MSG_AVAILABLE?
If NO_MSG_AVAILABLE, the messages are likely not yet committed.
_________________
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 |
|
|
| KoGor |
| Posted: Fri Feb 12, 2010 7:49 am Post subject: |
|
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
| Exactly, I get the message NO_MSG_AVAILABLE and as I said they are not committed because MQCMIT is not issued as I broke up the connection between MQ MGR and MQ Client. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Fri Feb 12, 2010 4:10 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| Non-persistent messages are discarded from queues at qmgr restart. |
Depends on the setting of NPMCLASS on the queues....
_________________
Glenn |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 12, 2010 4:40 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gbaddeley wrote: |
| bruce2359 wrote: |
| Non-persistent messages are discarded from queues at qmgr restart. |
Depends on the setting of NPMCLASS on the queues.... |
And whether it was a controlled shut-down...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Feb 13, 2010 7:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
This has nothing to do with persistence (he said the messages are persistent anyway).
The connection breaks, the UOW is outstanding, the q depth is > 0, at this point you cannot get the messages because they are not committed. When the QM is restarted the UOW is backed out and the q depth goes to zero.
The UOW should be backed out once the QM realizes the client connection is gone. When the connection breaks, does the SVRCONN channel still show as running on the QM side? If yes, that explains it. The QM still thinks the connection is valid and is waiting for the app to issue another MQ API call.
Rather than restarting the QM, try stopping the channel and see what happens.
Setting TCP Keep Alive to a value smaller than the default of 2 hours (set at the O/S) and then telling the QM to use Keep Alive will detect these orphaned channels and stop them for you.
In MQ 7, MQ clients can flow heartbeats both ways all the time, not just during MQGET with waits like pre MQ 7. These heartbeats will also help detect dropped connections.
If you can, upgrade to MQ 7.0.1.1 for both your client and Queue Manager. MQ 6 is going out of support in about a year anyway.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Feb 13, 2010 7:35 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| PeterPotkay wrote: |
| Setting TCP Keep Alive to a value smaller than the default of 2 hours (set at the O/S) and then telling the QM to use Keep Alive will detect these orphaned channels and stop them for you. |
Agree.
Alternatively, just tell MQ to use keepalive for channels, and leave the OS setting alone. The common default of 2 hours might well be enough for some situations.
A queue with a few uncommitted messages on it is not doing anyone any harm. If they are due to an errant client program, and keepalive is in use and working correctly, they should get tidied up eventually.
In the meantime, they cannot be MQGET-ed by any other application.
Or maybe the situation gets worse than this. You might have a severe buildup of uncommitted messages because of badly behaving client connections (networks, firewalls, apps not coded to call MQDISC, users ending their apps badly... etc.). In which case, lowering the keepalive interval in the OS is your only protection on the queue manager side. Maybe you would also need to look into why client connections were being broken before the MQDISC, too. Try to solve the problem on the client side as far as you can - it'll give you less work to do on the server side. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Feb 13, 2010 7:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| mvic wrote: |
| Alternatively, just tell MQ to use keepalive for channels, and leave the OS setting alone. |
KAINT for channels would only apply if the QM was z/OS.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaj.doc/sc11040_.htm
| Quote: |
KAINT
Although this parameter is available on all platforms, its setting is implemented only on z/OS. On platforms other than z/OS, you can access and modify the parameter, but it is only stored and forwarded; there is no functional implementation of the parameter. |
The description for Heartbeats in the MQ 7 MQSC manual out of date. It doesn't reflect the fact that as of MQ 7 Heartbeats can now flow for MQ Clients outside of an MQGET with wait call. The description in the Intercommunications manual is correct.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzae.doc/ic11720_.htm
I sent feedback to the Info center publishers to have that corrected.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Feb 13, 2010 8:56 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
|
|
