TCP/IP Connection usage between WebSphere Application Server V7 and V8, and WebSphere MQ V7 (and later) explained

Answer

WebSphere MQ V7 introduces a new feature called "sharing conversations", which allows multiple conversations to share TCP/IP channel instances (also known as a TCP/IP connection).

Applications running inside of WebSphere Application Server V7 and V8 that use WebSphere MQ messaging provider normal mode when connecting to a WebSphere MQ V7 (or later) queue manager will automatically make use of this new feature. This means that multiple applications running within the same application server instance that connect to the same WebSphere MQ queue manager will be able to share the same TCP/IP channel instance.

The number of conversations that can be shared across a single TCP/IP channel instance is determined by the WebSphere MQ channel property SHARECNV. The default value of this property for Server Connection Channels is 10.

By looking at the number of conversations that will be created by WebSphere Application Server V7 and V8, it is possible to determine the number of TCP/IP channel instances that will be created.


JMS Connection Factories
Applications running inside of WebSphere Application Server that use a WebSphere MQ messaging provider Connection Factory to create connections and sessions will have the following conversations active:

• One conversation for every JMS Connection that has been created from the Connection Factory.

Each JMS Connection Factory has an associated Connection Pool, which is divided up into two sections - the Free Pool and the Active Pool. Both the Free Pool and the Active Pool are initially empty.

When an application creates a JMS Connection from a Connection Factory, WebSphere Application Server checks to see if there is a JMS Connection in the Free Pool. If there is, it is moved to the Active Pool and given to the application. Otherwise, a new JMS Connection is created, put in the Active Pool and returned to the application. The maximum number of Connections that can be created from a Connection Factory is specified by the Connection Factory Connection Pool property Maximum connections. This property has the default value of 10.

After an application has finished with a JMS Connection and closed it off, it is moved from the Active Pool to the Free Pool, where it is available for reuse. The Connection Pool property Unused timeout defines how long a JMS Connection will stay in the Free Pool before it is disconnected. This property has the default value of 1800 seconds, which is 30 minutes.

When a JMS Connection is first created, a conversation between WebSphere Application Server and WebSphere MQ is started. This conversation remains active until the connection is closed because it has been in the Free Pool for longer than the value of the Unused timeout property.

• One conversation for every JMS Session that has been created from a JMS Connection.

Every JMS Connection that is created from a WebSphere MQ messaging provider Connection Factory has an associated JMS Session Pool, which work in the same way as Connection Pools. The maximum number of JMS Sessions that can be created from a single JMS Connection is determined by the Connection Factory Session Pool property Maximum connections. The default value of this property is 10.

A conversation is started when a JMS Session is first created, and will remain active until the JMS Session is closed because it has remained in the Free Pool for longer than the value of the Session Pool's Unused timeout property.

This means that the maximum number of conversations from a single Connection Factory to WebSphere MQ can be calculated using the following formula:

Maximum number of conversations =
Connection Pool Maximum Connections +
(Connection Pool Maximum Connections * Session Pool Maximum Connections)

The number of TCP/IP channel instances that will be created to allow this number of conversations to take place can be worked out using the following calculation:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

Any remainder from this calculation needs to be rounded up.

For a simple Connection Factory that is using the default value for the Connection Pool Maximum connections and the Session Pool Maximum connections properties, the maximum number of conversations that can exist between WebSphere Application Server and WebSphere MQ for this Factory is:

Maximum number of conversations =
Connection Pool Maximum Connections +
(Connection Pool Maximum Connections * Session Pool Maximum Connections)

= 10 + (10 * 10)
= 10 + 100
= 110

If this Connection Factory is connecting to WebSphere MQ using a channel that has the SHARECNV property set to 10, then the maximum number of TCP/IP channel instances that will be created for this Connection Factory is:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

= 110 / 10
= 11 (rounded up to nearest connection)

Activation Specifications
Message-driven bean applications that are configured to use an Activation Specification will have the following conversations active:

• One conversation for the Activation Specification to monitor a JMS Destination for suitable messages. This conversation is started as soon as the Activation Specification is started, and remains active until the Activation Specification is stopped.

• One conversation for every Server Session used to run a message-driven bean instance to process messages.


The Activation Specification Advanced Property Maximum server sessions specifies the maximum number of Server Sessions that can be active at any one time for a given Activation Specification. This property has the default value of 10. Server Sessions are created as they are needed, and are closed down if they have been idle for the period of time specified by the Activation Specification Advanced Property Server session pool timeout. The default value for this property is 300000 milliseconds, which equates to 5 minutes.

The conversations are started when a Server Session is created, and are stopped either when the Activation Specification is stopped or when a Server Session times out.

This means that the maximum number of conversations from a single Activation Specification to WebSphere MQ can be calculated using the following formula:

Maximum number of conversations = Maximum server sessions + 1

The number of TCP/IP channel instances that will be created to allow this number of conversations to take place can be worked out using the following calculation:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

Any remainder from this calculation needs to be rounded up.

For a simple Activation Specification that is using the default value for the Maximum server sessions property , the maximum number of conversations that can exist between WebSphere Application Server and WebSphere MQ for this Activation Specification is:

Maximum number of conversations = Maximum server sessions + 1
= 10 + 1
= 11

If this Activation Specification is connecting to WebSphere MQ using a channel that has the SHARECNV property set to 10, then the number of TCP/IP channel instances that will be created is:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

= 11 / 10
= 2 (rounded up to nearest connection)

Listener Ports running in ASF mode
By default, Listener Ports will run in ASF mode. ASF stands for "Application Server Facilities", and is part of the JMS 1,1 Specification that defines the mechanism which application servers should use to detect messages and deliver them to message-driven beans for processing.

Message-driven bean applications that have been set up to use Listener Ports in this default mode of operation will create the following conversations:

• One conversation for the Listener Port to monitor a JMS Destination for suitable messages.


Listener Ports are configured to use a JMS Connection Factory. When a Listener Port starts up, it requests a JMS Connection from the Connection Factory Free Pool. The Connection is returned to the Free Pool when the Listener Port is stopped.

Please refer to the JMS Connection Factories section above for details on how the Connection Pool is used, and how this affects the number of conversations to WebSphere MQ.

• One conversation for every Server Session used to run a message-driven bean instance to process messages.

The Listener Port property Maximum sessions specifies the maximum number of Server Sessions that can be active at any one time for a given Listener Ports. This property has the default value of 10. Server Sessions are created as they are needed, and make use of JMS Sessions taken from the Session Pool associated with the JMS Connection that the Listener Port is using.

If a Server Session has been idle for the period of time specified by the Message Listener Service custom property SERVER.SESSION.POOL.UNUSED.TIMEOUT, it is closed down and the JMS Session it was using is returned to the Session Pool Free Pool. The JMS Session will remain there until it is needed, or it is closed off because it has been idle in the Free Pool for longer than the value of the Session Pool's Unused timeout property.

Please refer to the JMS Connection Factories section above for details on how the Session Pool is used, and how the conversations between WebSphere Application Server and WebSphere MQ are managed.

This means that the maximum number of conversations from a single Listener Port to WebSphere MQ can be calculated using the following formula:

Maximum number of conversations = Maximum sessions + 1

The number of TCP/IP channel instances that will be created to allow this number of conversations to take place can be worked out using the following calculation:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

Any remainder from this calculation needs to be rounded up.

For a simple Listener Port that is using the default value for the Maximum sessions property , the maximum number of conversations that can exist between WebSphere Application Server and WebSphere MQ for this Listener Port is:

Maximum number of conversations = Maximum sessions + 1
= 10 + 1
= 11

If this Listener Port is connecting to WebSphere MQ using a channel that has the SHARECNV property set to 10, then the number of TCP/IP channel instances that will be created is:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

= 11 / 10
= 2 (rounded up to nearest connection)

Listener Ports running in non-ASF mode
Listener Ports can be configured to run in non-ASF mode. This changes the way the Listener Ports monitor JMS destinations. For more information on this mode of operation, and how to configure Listener Ports to use non-ASF mode, see the developerWorks article When to use ASF and non-ASF modes to process messages in WebSphere Application Server.

Message-driven bean applications that have been set up to use Listener Ports in non-ASF mode will create the following conversations:

• One conversation for every Server Session used to run a message-driven bean instance to process messages.

The Listener Port property Maximum sessions specifies the maximum number of Server Sessions that can be active at any one time for a given Listener Ports. This property has the default value of 10.

When running in non-ASF mode, a Listener Port monitoring a Queue Destination will automatically create the number of Server Sessions specified by the Listener Port property Maximum sessions. All of these Server Sessions make use of JMS Sessions taken from the Session Pool associated with the JMS Connection that the Listener Port is using, and continually monitor a JMS Destination for suitable messages.

If the Listener Port is configured to monitor a Topic Destination, the value of Maximum sessions is ignored and a single Server Session is used.

The Server Sessions used by a Listener Port running in non-ASF mode remain active until the Listener Port is stopped, at which point the JMS Sessions that they were using are returned to the Session Pool Free Pool for the JMS Connection that the Listener Port was using.

Please refer to the section above for details on how the Session Pool is used, and how the conversations between WebSphere Application Server and WebSphere MQ are managed.

This means that the maximum number of conversations from a single Listener Port, running in non-ASF mode and monitoring a Queue Destination, to WebSphere MQ can be calculated using the following formula:

Maximum number of conversations = Maximum sessions

For a Listener Port running in non-ASF mode and configured to monitor a Topic Destination, the number of conversations from the Listener Port to WebSphere MQ is:

Maximum number of conversations = 1

The number of TCP/IP channel instances that will be created to allow this number of conversations to take place can be worked out using the following calculation:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

Any remainder from this calculation needs to be rounded up.

For a simple Listener Port running in non-ASF mode that is using the default value for the Maximum sessions property and monitoring a Queue Destination, the maximum number of conversations that can exist between WebSphere Application Server and WebSphere MQ for this Listener Port is:

Maximum number of conversations = Maximum sessions
= 10

If this Listener Port is connecting to WebSphere MQ using a channel that has the SHARECNV property set to 10, then the number of TCP/IP channel instances that will be created is:

Maximum number of TCP/IP channel instances =
Maximum number of conversations /
SHARECNV for the channel being used

= 10 / 10
= 1