Free connection pool maintenance threads

Associated with each free connection pool is a pool maintenance thread, which monitors the free pool to ensure that the connections in it are still valid.

If the pool maintenance thread decides that a connection in the free pool needs to be discarded, the thread physically closes the JMS connection to IBM MQ .

How the pool maintenance thread works

Aged timeout

The amount of time a connection remains open.

Minimum connections

The minimum number of connections the connection manager keeps in the free pool of a connection factory.

Reap time

How often the pool maintenance thread runs.

Unused timeout

How long a connection remains in the free pool before it is closed.

By default, the pool maintained thread runs every 180 seconds, although this value can be changed by setting the connection pool Reap time property.

The maintenance thread looks at each connection in the pool, checks how long it has been in the pool, and how much time has elapsed since it was created and last used.

• Greater than the value of Minimum connections, the connection manager closes the connection.
• Equals the value of Minimum connections, the connection is not closed and remains in the free pool.

The default value of the Minimum connections property is 1, which means that, for performance reasons, the connection manager always attempts to keep at least one connection in the free pool.

The Unused timeout property has a default value of 1800 seconds. By default, if a connection is put back in the free pool and not used again for at least 1800 seconds, that connection is closed, provided that closing it, leaves at least one connection in the free pool.

This procedure prevents unused connections from becoming stale. To turn this feature off, set the Unused timeout property to zero.

If a connection is in the free pool, and the elapsed time since its creation is greater than the value of the Aged timeout property for the connection pool, then it is closed regardless of how long it has been since it was last used.

By default, the Aged timeout property is set to zero, which means that the maintenance thread never performs this check. Connections that have been around for longer than the Aged timeout property are discarded regardless of how many connections will remain in the free pool. Note that the Minimum connections property has no affect in this situation.

Disabling the pool maintenance thread

From the previous description, we can see that the pool maintenance thread does a great deal of work when active, particularly if there are a large number of connections in the free pool of the connection factory.

For example, suppose there are three JMS connection factories, with the Maximum connections property set to 10 for each factory. Every 180 seconds, three pool maintenance threads become active and scan the free pools for each connection factory respectively. If the free pools have many connections, the maintenance threads have much work to do, which can significantly impact performance.

We can disable the pool maintenance thread for an individual free connection pool by setting its Reap time property to zero.

Disabling the maintenance thread means that connections are never closed, even if the Unused timeout has elapsed. However, the connections can still be closed if the Aged timeout has passed.

When an application has finished with a connection, the connection manager checks to see how long the connection has existed, and if that period is longer than the value of the Aged timeout property, the connection manager closes the connection rather than returning it to the free pool.

Transactional implications of Aged timeout

As described in the previous section, the Aged timeout property specifies how long a connection to the JMS provider remains open before the connection manager closes it.

The default value for the Aged timeout property is zero, which means that the connection will never be closed because it is too old. We should leave the Aged timeout property at this value, because enabling Aged timeout can have transactional implications when using JMS inside of EJBs.

In JMS, the unit of a transaction is a JMS session, which is created from a JMS connection. It is the JMS session that is enlisted into transactions, and not the JMS connection.

Due to the design of the application server, JMS connections can be closed because the Aged timeout has elapsed, even if JMS sessions created from that connection are involved in a transaction.