Flush a datasource connection pool in JBoss EAP

Solution Verified - Updated -

Environment

  • Red Hat JBoss Enterprise Application Platform (EAP)
    • 7
    • 6

Issue

  • How do I flush or reset a datasource connection pool?
  • How can I flush only idle connections?
  • Does flush-all-connection-in-pool flush all (idle, active/in-use) connections in the datasource connection pool ?
  • Does flush-all-connection-in-pool immediately destroy active/in-use connections, or does it wait for completion?

Resolution

A connection pool can be flushed by executing a flush command in the JBoss Management Command Line Interface (CLI).

Flushing Idle Connections

The following CLI command will flush all idle connections from a datasource pool named "ExampleDS":

Standalone Mode

 /subsystem=datasources/data-source=ExampleDS/:flush-idle-connection-in-pool

Domain Mode

/host=master/server=server-one/subsystem=datasources/data-source=ExampleDS/:flush-idle-connection-in-pool

Notes
1. Connections which are reserved by application components (which have called DataSource.getConnection() but which have not returned the connection(s) to the pool by calling Connection.close()) are not idle and are not subject to the flush-idle-connection-in-pool command.
2. Flushing idle connections may drop the pool size below the min-pool-size specified for the pool.
3. If only idle connections are in the pool, and no inUse connections, the pool will be shut down and a new pool instance will be created in its place. This will invalidate cached DataSource references (caching of DataSource references is not recommended or supported).
4. For an xa-datasource, please use xa-data-source instead of data-source in the CLI command .

Flushing Invalid Connections

In JBoss EAP 7 and later, the flush-invalid-connection-in-pool command may be used to flush invalid connections that are presently idle (i.e. not reserved by application components) in the pool.

Standalone Mode

/subsystem=datasources/data-source=ExampleDS/:flush-invalid-connection-in-pool

Domain Mode

/host=master/server=server-one/subsystem=datasources/data-source=ExampleDS/:flush-invalid-connection-in-pool

Graceful Flush

In JBoss EAP 7 and later, the flush-gracefully-connection-in-pool command may be used to flush all idle connections immediately and flush active connections when they are returned to the pool (when application code explicitly calls Connection.close()).

Standalone Mode

/subsystem=datasources/data-source=ExampleDS/:flush-gracefully-connection-in-pool

Domain Mode

/host=master/server=server-one/subsystem=datasources/data-source=ExampleDS/:flush-gracefully-connection-in-pool

Flushing All Connections

As an alternative to the methods above, the following CLI command will flush all the connections from a datasource pool named "ExampleDS":

Standalone Mode

/subsystem=datasources/data-source=ExampleDS/:flush-all-connection-in-pool

Domain Mode

/host=master/server=server-one/subsystem=datasources/data-source=ExampleDS/:flush-all-connection-in-pool

Notes
1. The flush-all-connection-in-pool command kills all idle and in-use (i.e. reserved by application components) connections immediately1 and application components with open connections may encounter errors2. For this reason, the flush-all-connection-in-pool command is not recommended for production systems in most cases.
2. The pool will be shut down and a new pool instance will be created in its place. This will invalidate cached DataSource references (caching of DataSource references is not recommended or supported).
3. For an xa-datasource, please use xa-data-source instead of data-source in the CLI command .

  1. EAP6 differs from in behavior from EAP 5 where the command would wait until connections were closed (returned to the pool) before destroying them ↩︎

  2. Full flush can cause issues depending on how the application is coded. In general, even with fault tolerance, users need to code the application to handle exceptions raised while accessing connections. If an application component's connection handle is closed while it is still using it, the application is expected to catch the exception and unwind the thread stack "gracefully". Ordinarily, this does not result in crashes. However, depending on what the application does in handling the exception or if failing to handle it, sometimes unexpected things may happen. For this reason, this full flush is not normally recommended for a production system ↩︎

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments