Connection pooling configuration
Certain connectors support the ability to be pooled. For a pooled connector, OpenICF maintains a pool of connector instances and reuses these instances for multiple provisioning and reconciliation 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. Learn more in Pooling mechanisms.
For an unpooled connector, a new connector instance is initialized for every operation. When the operation has been run, OpenICF disposes of the connector instance. Learn more in Connector types.
Because the initialization of a connector is an expensive operation, reducing the number of connector initializations can substantially improve performance.
To configure 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.
Pooling mechanisms
If a connector depends on a third-party library that has its own pooling mechanism, then OpenICF 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
-
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
PoolableConnectorin the connector configuration file. Learn more about pooling configuration in Connection pooling configuration. - HTTP pooling
-
Certain connectors, which require an HTTP client, leverage
PoolingHttpClientConnectionManagerto 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.
- Connector-specific pooling
-
The connector implements the pooling and could include properties to configure the pool.
- Non-poolable connectors
-
OpenICF creates a new instance of the connector class and uses a new or existing instance of the connector configuration to initialize the instance before the operation runs. After the operation is run, OpenICF disposes of the connector instance.