| Author |
Message
|
| hartley |
 Posted: Fri Jan 16, 2009 4:14 am Post subject: Logically deleted reply queue after network outage |
 |
|
Novice
Joined: 09 Jun 2008
Posts: 10
|
Situation:
1. Client creates temporary dynamic reply queue.
2. Major network outage.
3. Client reconnects to broker and reopens reply queue by name.
4. Reply queue disappears later anyway.
These settings below seem to indicate that as long as we reconnect within 3 minutes then we should be OK.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"KeepAliveTime"=dword:0002bf20
"KeepAliveInterval"=dword:000003e8
"TcpMaxConnectRetransmissions"=dword:00000002
But has the reply queue been logically deleted and so can never be referenced and so never stays alive again? Is there anyway to restore a reply queue to full live status?
I know one answer would be to use a dead letter queue for clients to collect messages even though their reply queue has gone but wondering about how exactly the reply queue is going in the current situation.
Thanks for any help,
Hartley |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jan 16, 2009 4:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
A temporary dynamic queue is deleted when the queue manager thinks that the application that opened it has disconnected.
In the case of client apps, there *may* be a certain amount of latency between when the client app gets a network level MQRC that indicates the connection has gone away and when the qmgr thinks the client app has disconnected and deletes the queue.
There's no good sense at all in trying to rely on that in any way.
If an app needs to continue to receive REPLY messages across it's own disconnections, then the app needs to use a PERMANENT reply queue - either dynamic or not - rather than a TEMPORARY one.
If an app choses to use a Temporary dynamic queue, then it should always assume that it needs to create a new one every time it has to do an MQCONN. |
|
| Back to top |
|
|
| hartley |
| Posted: Fri Jan 16, 2009 4:31 am Post subject: |
|
|
Novice
Joined: 09 Jun 2008
Posts: 10
|
Thanks for the speedy confirmation Jeff!
We should definitely move to permanent reply queues but we haven't seen any way for them to be cleaned up in the case of abnormal client shutdown (this happens alot - some of our front office users are always 'end process'ing Excel or other apps! Would we have to implement something ourselves that looks for unused (ones without any input or output counts) reply queues and delete them?
Thanks,
Hartley |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 16, 2009 4:45 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well the real question is what do you want to do with the reply messages....
You current setup is suggesting that the client will have to query again because it got disconnected.
If this is not the case and you are using a truly asynchronous model you might have to setup some kind of persistent store on the requester side that holds the expected correlid identifier so that it can process in a true asynchronous manner the replies...
The alternative would be one permanent queue per store and process all messages on that queue...
If you are worried about stranded messages on a single replyto queue because the requester is never going to pick it up, check out the expiry option on messages....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hartley |
| Posted: Fri Jan 16, 2009 5:02 am Post subject: |
|
|
Novice
Joined: 09 Jun 2008
Posts: 10
|
Thanks for the reply fjb_saper.
We are not using a truly asynchronous model. It's more like a synchronous model assuming a perfect network due to our mistaken use of temporary dynamic reply queues  .
The stranded messages are a concern but as you say can easily be fixed with the expiry. So that's one problem solved.
What I am really wondering is if permanent reply queues can be automatically deleted (after abnormal client termination)? We have seen in the past that an empty reply queue will use resources on the broker e.g. the MaxMsgSize buffer and as ours is 8MB this can easily translate to huge wasted chunks of memory on the broker.
Any ideas? We were considering a kind of cleanup tool that scanned for unused reply queues but if there is something more inline with MQ that would be great to know.
Thanks,
Hartley. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 16, 2009 5:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hartley wrote: |
| What I am really wondering is if permanent reply queues can be automatically deleted (after abnormal client termination)? |
Didn't you already say they are?
| hartley wrote: |
| 4. Reply queue disappears later anyway. |
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/fg11020_.htm
| Quote: |
| They are deleted when the application that issued the MQOPEN call that created the queue closes the queue or terminates. |
For MQ Clients, once the QM realizes its gone (after TCP Keep Alive kicks in for abnormally terminated ones), they should go away.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hartley |
| Posted: Fri Jan 16, 2009 5:47 am Post subject: |
|
|
Novice
Joined: 09 Jun 2008
Posts: 10
|
Peter - you may have misread - trying to think of how to clean up permanent reply queues that hang around ...
Thanks,
Andrew |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 16, 2009 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hartley wrote: |
| Peter - you may have misread - trying to think of how to clean up permanent reply queues that hang around ... |
You're going to need some kind of external list (database?) of created queues & PIDs, coupled to an admin job that runs periodically and deletes queues connected to PIDs no longer in existence.
I don't envy you that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hartley |
| Posted: Fri Jan 16, 2009 7:27 am Post subject: |
|
|
Novice
Joined: 09 Jun 2008
Posts: 10
|
Yep, bit annoying but quite doable.
Am I wrong, or is this just because we don't have perfectly bug-free clients? What do others do if they have permanent reply queues but crashing clients?
A Hartley |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 16, 2009 7:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
As my most honoured associate says:
| mqjeff wrote: |
| If an app choses to use a Temporary dynamic queue, then it should always assume that it needs to create a new one every time it has to do an MQCONN. |
Typically in this model, a client which has failed & reconnects repeats the original enquiry; implicit in the reconnection is that the original reply is lost.
If you use a permanent queue, you'd retrieve the reply from a single permanently defined queue by correl id. If the client reconnects it can still attempt to read the reply, which will still be available if message expiry hasn't past. Often the same logic is used as for a temporary queue and the requestor simply repeats the request.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Fri Jan 16, 2009 7:47 am; edited 1 time in total |
|
| Back to top |
|
|
| hartley |
| Posted: Fri Jan 16, 2009 7:46 am Post subject: |
|
|
Novice
Joined: 09 Jun 2008
Posts: 10
|
| Ah OK thanks for that reply. That sounds very sane. Unlike the current way it works. Cheers! |
|
| Back to top |
|
|
|
|
