Author |
Message
|
kordi |
Posted: Sat Dec 07, 2013 7:53 am Post subject: Max number of active channels reached -what actions to take? |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Hello,
This is pretty common topic on this forum, but I'd like to summerize it a bit. I got this error recently when I wanted to make SDR-RCVR connection. What can I do with that?
1. I can stop qmgr, change MaxChannel/MaxActiveChannel values from 1000 to 3000, start it again. This can be done easily on DEV environment, on PROD it might be a bit difficult.
2. We can stop some SVRCONN channels. There are lots of SVRCONN channels, like 30 or more (I recently changed company and this environment is new to me). Stopping all channels is not a best option.
3. I can contact app administrators after dis conn command, identifying application by IP and ask them kindly to take a better look on their app code, because thay dont disconnect properly or they open a new connection for each mqput.
4. I can add KeepAlive=YES stanza to qm.ini but it just checks periodically if the other end of the connection is still available. If it is not, the channel is closed. I assume that app is still working there, but just dont handle connections right, so I dont know if it help.
5. I heard about exits that prevents app from making too many connections (this is set within exit)
What are your other suggestions?
Thanks in advance for help.
What are you suggestions? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sat Dec 07, 2013 12:41 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
You should do #4 no matter what, to have the queue manager clean up orphaned connections. Turning that on only tells the QM to use the operating system's setting so make sure that is turned on and set to an appropriate value. We have ours set to 15 minutes.
When you have reached Max Connections and need to do something NOW, you've basically listed all your options.
To avoid getting into that situation to begin with, exits like Capitialware's MQAUSX can be set on each channel to keep track of how many instances of it are running and to stop any one channel from taking to many instances. As of MQ 7 there are MQ channel parameters that can help you in this regard too - see MAXINST and MAXINTC.
For your #2 option, I would bet there is one offender that is taking up the majority of the connections because the app is not coded correctly and it keeps creating new connections. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Dec 07, 2013 3:19 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
On WMB7 use the option to limit each svrconn to a set number of instances. Discuss this with the people owning the application. No 2 apps should share the same svrconn... If they need more they will have to justify it, and you need to reassess max channels.
In the meantime it will prevent any one runaway app to use up all the channels as I'd expect it would hit the max inst, max instc before all connections are used up.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
kordi |
Posted: Sun Dec 08, 2013 1:36 pm Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Thanks a lot for your answers.
This is what I am gonna to do then. I will change max number of channels from 1000 to 3000, add KeepAlive=YES stanza to qm.ini and I will also start cleaning up this QMGR by identifying which SVRCONN have the the bigest number of active connection, and will contact app administrators asking for better look at code.
MQ version is 6.0.2.12
Thanks guys! |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Dec 08, 2013 2:38 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
kordi wrote: |
Thanks a lot for your answers.
This is what I am gonna to do then. I will change max number of channels from 1000 to 3000, add KeepAlive=YES stanza to qm.ini and I will also start cleaning up this QMGR by identifying which SVRCONN have the the bigest number of active connection, and will contact app administrators asking for better look at code.
MQ version is 6.0.2.12
Thanks guys! |
You also need to plan an upgrade path to V7.5.
V6.xxx of WMQ is no longer supported, unless you have extended support and then you're paying through the nose...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
kordi |
Posted: Sun Dec 08, 2013 2:41 pm Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Yes, you are right. We are moving to verion 7.0.1.7 currently but it takes time. |
|
Back to top |
|
 |
Tibor |
Posted: Mon Dec 09, 2013 4:51 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
kordi wrote: |
Yes, you are right. We are moving to verion 7.0.1.7 currently but it takes time. |
Upgrading to version v7.1 or v7.5 would be better, because MAXINST / MAXINSTC functionality (mentioned by PeterPotkay) is not implemented in v7.0. |
|
Back to top |
|
 |
exerk |
Posted: Mon Dec 09, 2013 5:02 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Tibor wrote: |
kordi wrote: |
Yes, you are right. We are moving to verion 7.0.1.7 currently but it takes time. |
Upgrading to version v7.1 or v7.5 would be better, because MAXINST / MAXINSTC functionality (mentioned by PeterPotkay) is not implemented in v7.0. |
I think you need to revisit the V7.0 Info Centre  _________________ 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 |
|
 |
Tibor |
Posted: Tue Dec 10, 2013 6:30 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
exerk wrote: |
I think you need to revisit the V7.0 Info Centre  |
Nice shot! It was mixed up with the channel specific ClientIdle (=DISCINT) setting. |
|
Back to top |
|
 |
kordi |
Posted: Tue Dec 10, 2013 2:47 pm Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Tibor You are right, but this is not up to me. I work in a big comapny and big comapnies have their big procedures thus everything takes a lot of time. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Dec 10, 2013 3:57 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
It takes just as much time to upgrade to 7.5.0.2 as it does to 7.0.1.7.
If you are stuck with going to 7.0.1, why not at least go to the latest fix pack straight away? Don't you want all the fixes in 7.0.1.8, and 7.0.1.9, and 7.0.1.10, and, well you get the point. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
kordi |
Posted: Wed Dec 11, 2013 1:25 am Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
You are 100% right. But as I mentioned before, I am not the one who decide. This is 50000+ company, development department is located on another continent and they are the one, who make decisions. And they decided to move from 6.x to 7.0x and unfortunately they didn't ask me for my opinion.
If it was up to me I would definately move to 7.1 or 7.5 to use new cool features like, for example, SET CHLAUTH
Cheers |
|
Back to top |
|
 |
hughson |
Posted: Wed Dec 11, 2013 4:09 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
|
Back to top |
|
 |
|