| Author |
Message
|
| shashivarungupta |
 Posted: Sat Jun 22, 2013 11:40 pm Post subject: ClientIdle Parameter |
 |
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Hi All,
In the Infrastructure Environment, recently a common issue was faced where number of server/client connections were piling up (default limit of 100) and Qmgr refused connection requests once limit reached.
As a sudden fix, Application Owner approved the request to bounce the server connection channel, to reduce the conection count.
But it was suggested if ClientIdle Parameter can be used to tune the functionality.
Where Application Owners are concerned about that proposal, because they're using listener based connection which goes inactive for a while if messages don't flow and becomes active when application sends messages., they use the same old connection. They were concerned whether ClientIdle would cause queue manager to flush off all those old inactive connections and would their application have to request new connection again ?
Would anyhow application code get affected by using ClientIdle , in case their application is using Listerner based Or Trigger based connections ?
(I'm not having visibility to their application code., how is that formulated, because that is Client Application Ownership not the Infrastructure's.)
Presently MQ Server version 7.0.1.3.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
 |
| shashivarungupta |
| Posted: Sat Jun 22, 2013 11:44 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
I forgot to capture a link for the same subject.
And wanted to know if someone of you've experienced any question/concern while ClientIlde Implemented in the System.
Server : Aix/Linux
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Jun 23, 2013 1:19 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Have you searched this forum for other topics on the subject?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Jun 23, 2013 4:47 am Post subject: Re: ClientIdle Parameter |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| shashivarungupta wrote: |
| Where Application Owners are concerned about that proposal, because they're using listener based connection which goes inactive for a while if messages don't flow and becomes active when application sends messages., they use the same old connection. They were concerned whether ClientIdle would cause queue manager to flush off all those old inactive connections and would their application have to request new connection again ? |
Yes, that is exactly what it would do. And probably not what you want to do.
| shashivarungupta wrote: |
| In the Infrastructure Environment, recently a common issue was faced where number of server/client connections were piling up (default limit of 100) and Qmgr refused connection requests once limit reached. |
What is an "Infrastructure Environment"?
100 is a very low number of max connections. Yes its the default.
But if that is the limit you want on your queue manager you should do some or all of these:
* Change the app so they need less concurrent connections
* Fix the app so they stop opening new connections when they have unused old connections
* move the app to another queue manager where you have more of the default 100 connections to spare
* limit the number of instances of this specific SVRCONN channel definition
As smdavies99 suggested, search. The pros and (in my opinion) mostly cons of ClientIdle have been discussed here before.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Jun 23, 2013 7:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You can also consider making the problem more interesting by playing around with SHARECNV. |
|
| Back to top |
|
|
| Tibor |
| Posted: Mon Jun 24, 2013 2:33 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
I could recommend using DISCINT (Disconnect Interval) channel attribute, if your MQ version is v7.1+. You can set channels individually with this.
Of course, you should increase the MaxChannels / MaxActiveChannels parameters, as Peter mentioned before. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 27, 2013 1:13 am Post subject: Re: ClientIdle Parameter |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| PeterPotkay wrote: |
| * limit the number of instances of this specific SVRCONN channel definition |
This is very good advise - using the parameters MAXINST and MAXINSTC.
It means that if any one application is "badly behaved" and is doing as was suggested above, opening more connections when it already has a perfectly good connection to use, it can only hurt itself and not any other applications on other channels.
Best advise is to ensure that the total of all your MAXINST is still less than MAXCHLS, so that you always still have 'room' to run other types of channels, senders and receivers for example, even when all client-svrconn pairings are filled up.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
