| Author |
Message
|
| Vitor |
 Posted: Wed Dec 27, 2006 6:49 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aayteka wrote: |
# stop channel(SYSTEM.ADMIN.SVRCONN) MODE(FORCE) STATUS(INACTIVE) conname(10.35.0.84)
|
Are you sure that's the right channel? Your applications are connecting via the system admin channel? Not a user defined one? Or even the default application one? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| aayteka |
| Posted: Wed Dec 27, 2006 7:02 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
Yes I'm sure,
But this channel has been created by me at the installation, please don't consider the name:)
I have created this channel as a server-connection channel. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 27, 2006 7:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aayteka wrote: |
But this channel has been created by me at the installation, please don't consider the name:)
|
If you have, you're off my map. That's the name of a channel defined during installation for use by MQExplorer amongst other things; or should be. If you've had to define it manually you're in unexplored territory.
For the record, MQ objects called SYSTEM.* are typcially reserved for use by the software. Normal people use other names. At a push an application might use SYSTEM.DEF.SVRCONN (again created automatically not manually at installation).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Dec 27, 2006 8:39 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| aayteka wrote: |
stop channel(SYSTEM.ADMIN.SVRCONN) MODE(FORCE) STATUS(INACTIVE) conname(10.35.0.84)
Result is same: AMQ9533: Channel 'SYSTEM.ADMIN.SVRCONN' is not cureently active. |
Does a "dis chstatus(SYSTEM.ADMIN.SVRCONN) conname(10.35.0.84)" give any results? Maybe you haven't got any outstanding connections from 10.35.0.84?
Try doing the stop channel(SYSTEM.ADMIN.SVRCONN) MODE(FORCE) STATUS(INACTIVE) without the conname attribute. Bear in mind that this will disconnect any channels which are currently actively used by your running application and will cause them to fail.
I am not sure how to enable keepalive on RedHat operating system. A quick search on google shows up there is some kind of sysctl command for modifying kernal parameters. You'll have to go read the redhat manuals or talk to the redhat sys admins.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| pathipati |
| Posted: Wed Dec 27, 2006 9:19 am Post subject: |
|
|
Master
Joined: 03 Mar 2006
Posts: 296
|
| Try using Mode (Terminate) |
|
| Back to top |
|
|
| KevinF23492 |
| Posted: Wed Dec 27, 2006 9:41 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 22
|
What on earth are you using the SYSTEM.ADMIN.SVRCONN for?
Is this a remote administration application?
My ROT says...avoid using SYSTEM* objects (and names) and you will avoid any potential for a world of hurt.  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 27, 2006 2:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scottj2512 wrote: |
Bear in mind that this will disconnect any channels which are currently actively used by your running application and will cause them to fail.
|
And given what uses that channel it's not perhaps the best idea.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aayteka |
| Posted: Thu Dec 28, 2006 1:07 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
| Quote: |
| Does a "dis chstatus(SYSTEM.ADMIN.SVRCONN) conname(10.35.0.84)" give any results? Maybe you haven't got any outstanding connections from 10.35.0.84? |
I have run this command and it gives many results as expected. In all the results the STATUS of a connection is STOPPING.
So I still can't close the connections.
Also I haven't recreated the SYSTEM.ADMIN.SVRCONN. It was not in the existing list.
thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 28, 2006 1:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
1) If the installation of MQSeries did not result in the automatic creation of SYSTEM.ADMIN.SVRCONN then something very odd and probably bad happened. Given that other odd and probably bad things are happening I would worry about that in your place.
2) As I and other posters have said, DO NOT use SYSTEM objects for application use. Define another channel and use that instead. Anything could be using the SYSTEM channel and this could be why it won't stop.
3) Modify your processes so agent processes are not just killed.
4) Find a sys admin and ask about keepalive on RedHat
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu Dec 28, 2006 4:44 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| Vitor wrote: |
| 1) If the installation of MQSeries did not result in the automatic creation of SYSTEM.ADMIN.SVRCONN then something very odd and probably bad happened. Given that other odd and probably bad things are happening I would worry about that in your place. |
I'm pretty sure that SYSTEM.ADMIN.SVRCONN channel is not created by default via crtmqm command. If you are on Windows and use MQExplorer to create a qmgr, you can check the "Create server connection channel to allow remote admin of qmgr over TCP/IP". If you leave that unchecked you don't get a SYSTEM.ADMIN.SVRCONN channel. You can of course create it yourself (we do on AIX).
This is with MQ5.3. Thing may be different on 6.0, I'm not sure.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| pathipati |
| Posted: Thu Dec 28, 2006 4:49 am Post subject: |
|
|
Master
Joined: 03 Mar 2006
Posts: 296
|
| Even in MQ 6.0, SYSTEM.ADMIN.SVRCONN channel is not created by default via crtmqm command. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 28, 2006 5:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Well a wise man once said "Never assume you know everything". I think it was me.... 
I'd have sworn SYSTEM.ADMIN.SVRCONN was one of the created objects and that shows what you get for swearing. I stand by my assertion that using SYSTEM objects for application programs is not recommended, especially with a name that software processes (like remote administration tools) look for.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sasmita10 |
| Posted: Fri Jan 05, 2007 8:44 am Post subject: MaximumChannel Connection reached |
|
|
Novice
Joined: 23 Feb 2005
Posts: 24
Location: Danbury, CT
|
Hi
We are having this problem almost everyday now. The queue manager is reaching the max channnel connection limit. I checked the qm.ini. We have increased upto 500.
What do I know that which connection is orphaned. If I stop the Server channel it will impact the application. We are restarting the Queue manager when this problem happens.
Please suggest me a better solution to resolve thsi issue.
Thanks
Sasmita
_________________
WMQ and WMQI specialist
(IBM Certified Web Sphere MQSeries 6.0 System Administrator )
(IBM Certified Web Sphere Message Broker 6.1 System Administrator ) |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Jan 06, 2007 12:32 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Why don't you start to isolate who or what is causing the problem?
On the server with the queue manager, do the following command:
| Code: |
| netstat -an | grep #### |
where ### is the port number.
Every IP address that is connecting to the queue manager should be easily identifiable. Any IP address that is unknown should be immediately shut down.
Next count / group the connections from each server.
| Code: |
| netstat -an | grep #### | grep 1.1.1.1 | wc -l |
Does your actual count match what the application group/team said they would be using? If not then shutdown the application.
In 20 minutes, you should be able to identify exactly who / what is causing the problem.
A proper MQ standard for channel management is to assign each application their own unique channel.
i.e. ABC.XXX.CH01
Finally, what tool are you using to management the channels? May I suggest you take a look at MQ Standard Security Exit
One of its many features is to control / limit the number of connections per channel.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
