WebSphere Application Server and WebSphere MQ do not agree on the number of JMS connections
The WebSphere Application Server JMS connections to WebSphere MQ does not equal the number of Server Connection channel instances in WebSphere MQ.
Resolving the problem
This is working as designed.
When an MQ Client application is running in WAS using the MQ JMS Provider and is connected to an MQ queue manager there is no direct correlation between the number of JMS Client connections to the WebSphere MQ queue manager and the number of Server Connection channels running on the queue manager. This is because of connection caching.
On the client side there is caching of connections that happens in both the client and WAS:.
1. In the Java™ Client (MQQueueManager pool)
2. WebSphere Application Server Connection Handles (JCA Pool)
The number of Server Connection channels on the MQ queue manager will grow depending on the load. When the connection is closed, the connection handle associated with that connection is released and sent back into the WAS JCA pool.
However, even after they are cleaned up from the JCA pool, it does not mean the number of active channels on the MQ queue manager will drop. This is because the objects that constitute the network presence are still cached at the Java client level (MQQueueManager objects). The reap of these objects is performed by the MQSimpleConnectionManager object - see Supplying a different connection pool in WebSphere MQ classes for Java™. This destroys connections on a least-recently-used basis. A connection is destroyed if it has not been used for 5 minutes, or if there are more then 10 unused connections in the pool.
The number of active channels will be a little more than (because of preemptive caching) the highest number of Connections used simultaneously in the last (JCA reap time + MQ Java reap time) minutes.
In short, because of the way connections are cached and managed in both the MQ Client code and the WAS JCA layer the number of active connection on the Client side may not be the same as the number of Server Connection channels on the MQ queue manager side.
With regard to MaxChannels, there is no way to predict exactly what value to set this to at any given moment due to the dynamic nature of connections/disconnections and caching. However, the default settings for a Queue Connection Factory (QCF) are:
Each Client connection has its own session pool. Therefore, with the default settings above, each connection will get 10 sessions. Since there are 10 connections in the pool and 10 sessions per connection this permits a maximum of 100 actual socket connections to MQ. Therefore MaxChannels on the MQ Queue Manager should be AT LEAST this value. A safe practice would be to set MaxChannels to 1000, although you may want to use a smaller value if your system is resource constrained. If you change the Connection Pooling default values be sure to adjust MaxChannels accordingly.
|Application Servers||WebSphere Application Server|
More support for:
Software version: 6.0, 7.0, 7.1, 7.5
Operating system(s): AIX, Linux, Solaris, Windows
Reference #: 1194456
Modified date: 16 April 2013