Pool maintenance thread examples

Using the Enterprise Java Bean (EJB) example to understand how the pool maintenance thread works. Note that you can also use Message Driven Beans (MDBs) and listener ports, as all you need is a way to get connections in the free pool.

See How applications that perform outbound messaging use the connection pool for further details of the sendMessage() method.

You have configured the connection factory with the following values:
  • Reap time at its default value of 180 seconds
  • Aged timeout at its default value of zero seconds
  • Unused timeout set to 300 seconds
After the application server starts up, the sendMessage() method is invoked.

The method creates a connection called, for example c1, using the factory jms/CF1, uses that factory to send a message, and then calls connection.close(), which causes c1 to be put into the free pool.

After 180 seconds, the pool maintenance thread starts up, and looks at the jms/CF1 free connection pool. There is a free connection c1 in the pool, so the maintenance thread looks at the time the connection was put back, and compares this to the current time.

180 seconds have passed since the connection was put in the free pool, which is less than the value of the Unused timeout property for jms/CF1. Therefore the maintenance thread leaves the connection alone.

180 seconds later, the pool maintenance thread runs again. The maintenance thread finds the connection c1, and determines that the connection has been in the pool for 360 seconds, which is longer than the Unused timeout value set, so the connection manager closes the connection.

If you now run the sendMessage() method again, when the application calls connectionFactory.createConnection() , the connection manager creates a new connection to IBM® MQ because the free connection pool for the connection factory is empty.

The preceding example shown how the maintenance thread uses the Reap time and Unused timeout properties to prevent stale connections, when the Aged timeout property is set to zero.

How does the Aged timeout property work?

In the following example, assume that you have set the:
  • Aged timeout property to 300 seconds
  • Unused timeout property to zero.

You invoke the sendMessage() method and this method tries to create a connection from the jms/CF1 connection factory.

As the free pool for this factory is empty, the connection manager creates a new connection, c1, and returns it to the application. When sendMessage() calls connection.close(), c1 is put back into the free connection pool.

180 seconds later, the pool maintenance thread runs. The thread finds c1 in the free connection pool, and checks how long ago it was created. The connection has existed for 180 seconds, which is less than Aged timeout, so the pool maintenance thread leaves it alone and goes back to sleep.

60 seconds later, sendMessage() is called again. This time, when the method calls connectionFactory.createConnection(), the connection manager discovers that there is a connection, c1, available in the free pool for jms/CF1. The connection manager takes c1 out of the free pool, and gives that connection to the application.

The connection is returned to the free pool when sendMessage() exits. 120 seconds later, the pool maintenance thread wakes up again, scans the contents of the free pool for jms/CF1 and discovers c1.

Although the connection was only used 120 seconds ago, the pool maintenance thread closes the connection, because the connection has been in existence for a total of 360 seconds, which is longer than the 300 second value you set for the Aged timeout property.

How the Minimum connections property affects the pool maintenance thread

Using the How MDB listener ports use the connection pool example again, assume that you have two MDBs deployed in your application server, each using a different listener port.

Each listener port is configured to use the jms/CF1 connection factory, which you have configured with the:
  • Unused timeout property set to 120 seconds
  • Reap time property set to 180 seconds
  • Minimum connections property set to 1

Suppose that the first listener is stopped, and its connection c1 is put into the free pool. 180 seconds later, the pool maintenance thread wakes up, scans the contents of the free pool for jms/CF1, and discovers that c1 has been in the free pool for longer than the value of the Unused timeout property for the connection factory.

However, before closing c1, the pool maintenance thread looks to see how many connections will remain in the pool if this connection is thrown away. Since c1 is the only connection in the free connection pool, the connection manager does not close it, because doing so would make the number of connections that remain in the free pool less than the value set for Minimum connections.

Now, assume that the second listener is stopped. The free connection pool now contains two free connections - c1 and c2.

180 seconds later, the pool maintenance thread runs again. By this time, c1 has been in the free connection pool for 360 seconds, and c2 for 180 seconds.

The pool maintenance thread checks c1 and discovers that it has been in the pool for longer than the value of the Unused timeout property.

The thread then checks to see how many connections are in the free pool, and compares this to the value of the Minimum connections property. Since the pool contains two connections, and Minimum connections is set to 1, the connection manager closes c1.

The maintenance thread now looks at c2. This has also been in the free connection pool for longer than the value of the Unused timeout property. However, since closing c2 would leave the free connection pool with less than the set number of Minimum connections in it, the connection manager leaves c2 alone.