| Author |
Message
|
| McueMart |
 Posted: Thu Mar 13, 2014 7:26 am Post subject: Cluster Receiver channel holding queue handle open |
 |
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Hi guys,
We are encountering a bit of a problem whereby we want to be able to create clustered queues and remove them in quite an 'agile' way (dont ask....).
One problem I have spotted is that despite removing a queue from the cluster, and PUT inhibiting it, it will still have an open queue handle from the amqrmppa ( Channel agent) process for quite a long time (Is this related to the Cluster Receive channel disconnect interval?).
Due to this outstanding queue handle, we are unable to delete it. Can anyone thing of a way to forcefully disconnect this handle (without stopping the QM!) ? In theory this should be fine as we have taken this queue out of the cluster and PUT inhibited it so it will receive no further messages.
Cheers! |
|
| Back to top |
|
 |
| sandman147 |
| Posted: Thu Mar 13, 2014 11:34 am Post subject: |
|
|
Apprentice
Joined: 01 Sep 2013
Posts: 42
|
I think the general bookish approach while removing a Q from a cluster:
1) Indicate to the other QM's in the cluster that the Q is no longer avaiable
ALTER QLOCAL<> CLUSTER('')
2)Disable the Q so no further msgs can be written to it
ALTER QLOCAL PUT(DISABLED)
3)Make sure no indoubt msgs on the cluster channel
4)Delete Q |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Mar 14, 2014 1:34 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Hi sandman - yes this is pretty much what we are doing. But as I mention, we have this annoying open queue handle from the channel agent which stays for some random (??) period of time preventing us from being able to delete it. Im wondering if there is some kind of PCF command which can be sent to 'kill' a connection? Sounds dirty, but if it's the only way... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 14, 2014 6:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Have you considered altering the properties of the cluster receiver? |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Mar 14, 2014 6:53 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Which properties do you think I should look at? From my knowledge only Disconnect Interval and Heartbeat Interval are anything related to this, and they govern the channel as a whole (i.e. whether it should be RUNNING or INACTIVE)
In my situation there will still be messages flowing over the channel (going to other queues...), but it is just 1 particular queue which has been removed from the cluster and now needs to be removed which still has the channel agent handle on it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 14, 2014 10:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Open a PMR. There is a channel Stanza that you might want to add to your qmgr. By default the channel caches about 100 handles... if the reuse factor interferes with the cache and availability of dynamic response queues there is a stanza that allows you to reduce the numbers of queues in the channel cache....
Hope this helps... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Jun 18, 2014 12:48 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
After further playing/investigation, I still haven't found a way to 'disconnect' the channel agent from queues when I need them to be.
I have seen Morag browsing the forums in recent days so im going to shamelessly bump this post in the hope of a reply from her 
(We are using MQ 7.5 for further info - but would happily move to v8 if anything new could help!) |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jun 18, 2014 3:13 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
She probably doesn't follow Message Broker forum.
Maybe you should post a topic on WMQ forum with a link pointing here? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jun 18, 2014 3:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Moved to Clustering Forum.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Jun 18, 2014 3:41 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Thanks! Thought I had put it in a MQ forum in the first place - apologies! |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Jun 18, 2014 6:09 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
If I remember correctly a queue gets closed when.......
- The queue cache is full - I believe this is 200 by default
- The queue is not used for 15 minutes
- The channel is idle and send/received a heartbeat
You can affect 2 of these
- You can reduce the size of the cache
You could then, if you were desperate artificially fill the cache yourself.
- You could reduce the heartbeat interval
Are you sure though that it's a good idea to be constant creating and destroying queues in the cache? That could generate a lot of chatter and log forced. How frequently will you be doing this?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 18, 2014 6:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Paradoxically, reducing the number of queues in the cache, if you work a lot with dynamic response queues, is a good thing...
One of the problems presented by the cache is a high churn of dynamic response queues that are then not available to be passed back to the pool and reused as long as they are being held by the (channel) cache ...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Jun 18, 2014 7:52 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Thanks for the replies guys.
@Paul - Could you provide any guidance in regards to how I can (1) Reduce the size of the queue cache and (2) Artificially fill the cache. My googling skills are failing me.
Also in regards to the queue getting closed after 15 minutes of inactivity - can you remember if this was a 'hardcoded' value? That would be perfect if I could configure that!
In regards to reducing the heartbeat - as I mentioned, the channel will not be idle; there will still be lots of messages flowing over it into other queues so I dont think this'll do the job.
| Quote: |
| Are you sure though that it's a good idea to be constant creating and destroying queues in the cache? That could generate a lot of chatter and log forced. How frequently will you be doing this? |
Let me give a little bit of background to make what we are doing more clear. We are making deployable 'Roles'. A role package may include Message Flow, MQ objects (queues, topics etc), Databases etc. When we 'deploy' the role to a machine, we obviously create and deploy all the artifacts. When it comes time to remove the role, we want to be able to cleanly remove all the role artifacts. This is easy for Database and Message Flows, but we have hit the issue with MQ queues as I have highlighted in this thread. Hopefully this makes it a bit more clear why I want to be able to remove queues in this 'agile' manner! |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Jun 18, 2014 8:28 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
Well, to change the channel Queue Cache size you can add something like the following to your QM.INI file.
| Code: |
Channels:
QueueCacheSize = 10
|
As for artificially filling the cache I wasn't necessarily serious. As I said, you would need to be desperate. But you could, if you really wanted to, send messages down the channel which would cause the cache to fill with 'other' queues. The fact that these are cluster channels makes it a little more awkward since you need to arrange for these messages to flow down the channel.
I'm afraid the 15 minutes is, I believe, hard coded. It's perhaps surprising, after all these years, that no one has asked for the value to be configurable. It would be very trivial to do.
As for what you are doing it sounds as though this is not not happening too frequently so there are no problems from a performance point of view. Deploying and removing an application should be a relatively rare action. Have you considered making it a two step process? For example, operationally:
- Application is 'disabled' in some way on day 1
- 24 hours later if no one has complained then the Application is removed
There is something to be said for not tearing down something immediately but giving people time to see whether it causes a problem. Of course I don't understand your environment or requirements so it may be totally inappropriate.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
