Connection pooling configuration
Certain connectors can be pooled, while other connectors are non-poolable. Learn more about the five Pooling mechanisms used in OpenICF and understand Connectors by pooling mechanism.
Pooling mechanisms
If a connector depends on a third-party library that has its own pooling mechanism, then ICF leverages that pooling mechanism. For example, an HTTP connector uses an Apache HTTP client and a DB connector uses a Tomcat JDBC.
OpenICF uses an ICF pooling mechanism only if:
-
A connector has no third-party library pooling mechanism, or
-
If OpenICF can’t control the amount of connections the third-party library uses. For example, the Microsoft Graph API connector.
OpenICF uses the following pooling mechanisms to manage connections.
ICF pooling
ICF pooling maintains connector objects and is managed by the framework. This pooling mechanism improves throughput and is used by, and is only relevant to, the connectors that implement the PoolableConnector interface.
For an ICF-pooled connector, ICF maintains a pool of connector instances and reuses these instances for connector operations. When an operation must be run, an existing connector instance is taken from the connector pool. If no connector instance exists, a new instance is initialized. When the operation has been run, the connector instance is released back into the connector pool, ready to be used for a subsequent operation.
The following example shows a pool configuration option object for an ICF poolable connector:
{
"maxObjects" : 10,
"maxIdle" : 10,
"maxWait" : 150000,
"minEvictableIdleTimeMillis" : 120000,
"minIdle" : 1
}To configure ICF connection pooling, set the following values in the connector configuration file poolConfigOptions property:
maxObjects-
The maximum number of connector instances in the pool, both idle and active. The default value is
10instances. maxIdle-
The maximum number of idle connector instances in the pool. The default value is
10idle instances. maxWait-
The maximum period to wait for a free connector instance to become available before failing. The default period is
150000milliseconds, or 150 seconds. minEvictableIdleTimeMillis-
The minimum period to wait before evicting an idle connector instance from the pool. The default period is
120000milliseconds, or 120 seconds. minIdle-
The minimum number of idle connector instances in the pool. If
minIdle=0, then a connector pool cleaner thread will run and close expired connections.
HTTP pooling
Connectors that use HTTP pooling require an HTTP client and leverage PoolingHttpClientConnectionManager to manage a pool of HTTP connections. Each connector defines and supports different properties that configure the pooling connection manager.
JDBC connectors
This pooling mechanism applies to connectors interacting with a database. A Tomcat JDBC driver handles the pooling.