| Author |
Message
|
| neo14884 |
 Posted: Thu Jul 23, 2009 1:38 am Post subject: AMQ9513: Maximum number of channels reached |
 |
|
Newbie
Joined: 31 Dec 2008
Posts: 4
|
Hi,
Currently we are getting AMQ9513: Maximum number of channels reached in mq error logs.
We have MQ 5.3 on a Solaris Platform.
The Java code uses the AMI API to connect to the MQ Manager to carry out a-sync message transfer.
Here is the error what i found in Application log:
Failed to create a new open SessionThread, check the MQManager try again. [AmException] completionCode[2] reasonCode[110] className[AmSession] methodName[open]:
No SessionThread available, Communication errorAMRC_TRANSPORT_NOT_AVAILABLE ErrorCode(110) ReasonCode(0) ErrorSource(AMI)
AMRC_TRANSPORT_NOT_AVAILABLE ErrorCode(110) ReasonCode(0) ErrorSource(AMI) Message Source = Policy = Service =
I guess this arises because there was no channels available for the AMI to get in contact with MQ Mnager.
This has happened twice in the last 15 days and for the past 4 years there was no such problem happening.
Restarting the MQ Manager had solved the problem both the times. I am thinking this will happen again.
The MQ manager is shared by different applications.
The QM.ini has:
Channels:
MaxChannels=1000
MaxActiveChannels=1000
MaxInitiators=10
AdoptNewMCA=ALL
AdoptNewMCACheck=ALL
Have gone through the other threads related to same issue and have understood that :
1.The problem happens either because of huge load on the Manager that the connections got exhausted.
2. Or a badly written code used the channel or using the channel for some reason couldn't release the channel back to the pool.
My question would be is there any way we will be able to see in MQ manager logs or any commands that can be executed on MQ prompt to check which was the queues/application which was using up all the connections in the pool and never returned it back.
Have to tell you we do not have access to the QManager since this is a Production environment and we have to provide the supporting vendor with commands/file requests to get what we need.
We are considering the option of increasing the channels from 1000 to 3000. Your comments on this...
Please help on tracing the reason why the channels got exhausted in the first place. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jul 23, 2009 1:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Points that occur:
- tell the supporting vendor that if they'd upgraded to a supported version from v5.3 you could raise a PMR with IBM rather than relying on a volunteer forum (do you pay for them to support it?)
- 1000 is not a lot for a production environment unless the server is ridiculously small. 3000 isn't that large, but you should still ensure that you don't have an application that's not disconnecting (or any pool will eventually fill)
- AMI is functionally stabalised & you should consider using something else
- you can obtain a list of open handles via the display command & match that with applications which are not actually running
Other diagnostic methods are undoubtably possible and may be better
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| neo14884 |
| Posted: Thu Jul 23, 2009 2:13 am Post subject: |
|
|
Newbie
Joined: 31 Dec 2008
Posts: 4
|
@Vitor
1- this is multi vendor supported application and we support the front end of it. The came back saying that they support MQ as COTS.
So we have to feed them everything.
2-(or any pool will eventually fill) - yes that was what my concern as well.
3- Will you be able to provide me some commands that can be used to check these. I am much of a java resource than an MQ.
Last edited by neo14884 on Thu Jul 23, 2009 2:30 am; edited 2 times in total |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Jul 23, 2009 2:18 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| neo14884 wrote: |
3- Will be able able to provide me some commands that can be used to check these. I am not much of a java resource than an MQ. |
If memory serves me right....
dis chstatus(CHANNELNAME)
You can also see this through MQExplorer |
|
| Back to top |
|
|
| neo14884 |
| Posted: Thu Jul 23, 2009 2:40 am Post subject: |
|
|
Newbie
Joined: 31 Dec 2008
Posts: 4
|
@WMBDEV1
I think the DISPLAY CHSTATUS(--generic-channel-name--) command will give the status of the channel currently.
Will it be possible to see the access history of this channel so that the queues which accessed it can be known. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 23, 2009 2:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| neo14884 wrote: |
1- this is multi vendor supported application and we support the front end of it. The came back saying that they support MQ as COTS.
So we have to feed them everything. |
Feed them an instruction to upgrade to at least v6. That way you'll be able to get support from IBM. Helpful if you've more Java than WMQ skills. It's also free!
(Alright, free with the WMQ license) 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| neo14884 |
| Posted: Thu Jul 23, 2009 2:50 am Post subject: |
|
|
Newbie
Joined: 31 Dec 2008
Posts: 4
|
@Vitor
Probably the client will not agree to an upgrade since the application has been stable for the lat 4 to 5 years. Also they are planning to develop an entire NEW application and phase out the current one... |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 23, 2009 3:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| neo14884 wrote: |
| Probably the client will not agree to an upgrade since the application has been stable for the lat 4 to 5 years. Also they are planning to develop an entire NEW application and phase out the current one... |
I hope the OS is stable as well as the rest of the software stack.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
