Advanced connection pool properties

There are a number of advanced properties that can be used to control the behavior of JMS connection pools.

Surge protection

How applications that perform outbound messaging use the connection pool describes the use of the sendMessage()method, which incorporates connectionFactory.createConnection().

Consider the situation where you have 50 EJBs all creating JMS connections from the same connection factory as part of their ejbCreate() method.

If all of these beans are created at the same time, and there are no connections in the free connection pool of the factory, the application server tries to create 50 JMS connections to the same JMS provider simultaneously. The result is a significant load on both WebSphere Application Server and the JMS provider.

The surge protection properties can prevent this situation by limiting the number of JMS connections that can be created from a connection factory at any one time, and staggering the creation of additional connections.

• Surge threshold
• Surge creation interval.

When EJB applications try to create a JMS connection from a connection factory, the connection manager checks to see how many connections are being created. If that number is less than or equal to the value of the surge threshold property, the connection manager continues opening new connections.

However, if the number of connections being created exceeds the surge threshold property, then the connection manager waits for the period of time specified by the surge creation interval property before creating and opening a new connection.

Stuck connections

A JMS connection is considered stuck, if a JMS application uses that connection to send a request to the JMS provider, and the provider does not respond within a certain amount of time.

• Stuck Time Timer
• Stuck Time
• Stuck Threshold

Pool maintenance thread examples explains how the pool maintenance thread runs periodically and checks the contents of the free pool of a connection factory, looking for connections that have either gone unused for a period of time, or have been in existence for too long.

To detect stuck connections, the application server also manages a stuck connection thread that checks the state of all active connections created from a connection factory to see if any of them are waiting for a reply from the JMS provider.

When the stuck connection thread runs is determined by the Stuck time timer property. The default value for this property is zero, which means that stuck connection detection never runs.

If the thread finds one waiting for a response, it determines how long it has been waiting, and compares this time to the value of the Stuck time property.

If the time taken for the JMS provider to respond exceeds the time specified by the Stuck time property, the application server marks the JMS connection as stuck.

For example, suppose the connection factory jms/CF1 has the Stuck time timer property set to 10, and the Stuck time property set to 15.

The stuck connection thread becomes active every 10 seconds, and checks if any connection created from jms/CF1 has been waiting for longer than 15 seconds for a response from IBM MQ .

Suppose an EJB creates a JMS connection to IBM MQ using jms/CF1, and then tries to create a JMS Session using that connection by calling Connection.createSession().

However, something is preventing the JMS provider from responding to the request. Perhaps the machine has frozen, or a process running on the JMS provider is deadlocked, preventing any new work from being processed:

Ten seconds after the EJB called Connection.createSession(), the stuck connection timer becomes active, and looks at the active connections created from jms/CF1.

Assume there is only one active connection, for example called c1. The first EJB has been waiting 10 seconds for a response to a request it sent down to c1, which is less than the value of Stuck time, so the stuck connection timer ignores this connection and becomes inactive.

10 seconds later, the stuck connection thread becomes active again, and looks at the active connections for jms/CF1. As before, assume that there is only the one connection, c1.

It is now 20 seconds since the first EJB called createSession(), and the EJB is still waiting for a response. 20 seconds is longer than the time specified in the Stuck time property, so the stuck connection thread marks c1 as stuck.

If, five seconds later, IBM MQ finally responds, and allows the first EJB to create a JMS Session, the connection is back in use.

The application server counts the number of JMS connections created from a connection factory that are stuck. When an application uses that connection factory to create a new JMS Connection, and there are no free connections in the free pool of that factory, the connection manager compares the number of stuck connections to the value of the Stuck threshold property.

If the number of stuck connections is less than the value set for the Stuck threshold, property, the connection manager creates a new connection and gives it to the application.

However, if the number of stuck connections is equal to the value of the Stuck threshold property, the application gets a resource exception.

Pool partitions

• Number of free pool partitions tells the application server how many partitions we want to divide the free connection pool into.
• Free pool distribution table size determines how the partitions are indexed.

Leave these properties at their default values of zero, unless we are asked to change them by the IBM Support Center.

Note that WebSphere Application Server has one additional advanced connection pool property called Number of shared partitions. This property specifies the number of partitions used to store shared connections. However, as JMS connections are always unshared, this property does not apply.