JMS connection pool sizes

You can increase the maximum connection pool size to allow for greater concurrency. Note that if only one deployed application is obtaining connections from a particular connection factory, there is no benefit in increasing the maximum queue connection pool size beyond the maximum concurrency, as configured within the activation specification.

The maximum connection pool size specifies the maximum number of physical connections that you can create in this pool. These are the physical connections to the back-end resource. After this number is reached, no new physical connections are created and the requester waits until a physical connection that is currently in use returns to the pool, or a ConnectionWaitTimeout exception is issued.

For example, if the Maximum Connections value is set to 5, and there are five physical connections in use, the pool manager waits for the amount of time specified in Connection Timeout for a physical connection to become free. The threads waiting for connections to underlying resource are blocked until the connections are freed up and allocated to them by the pool manager. If no connection is freed in the specified interval, a ConnectionWaitTimeout exception is issued.

If the Maximum Connections value is set to 0, the connection pool is allowed to grow infinitely. This causes the Connection Timeout value to be ignored.

When listener ports are involved, the connection factory pool sizes need to take this into consideration. The connection pool of the connection factory must be larger than the number of listener ports, and the session pool of the connection factory must be large enough to cover the maximum sessions value for any listener port using the connection.

For more information about the Listener Port settings, Message Listener thread pools, and the connection factory setting, see the Performance tuning for Java™ Messaging Service on WebSphere® Application Server on z/OS® article.