Description
Connection Pool
Client should implement connection pooling. Application or upper level library may have own connection pooling logic and the client should support option to turn own implementation off. It should let to use client-per connection when needed. Transport layer may have own connection pool, too. In such case it should be possible to pass configuration to transport layer as set of custom parameters or a raw configuration. None of settings should be replicated in client configuration
Note 1: It is important how connection pool handles failures. For example, server becomes unavailable and causes many connections to fail making some pool libraries
failing completely even after server work restoration.
Note 2: Most performant CP is HikariCP but it supports only JDBC connection pooling. It is possible to wrap client instance with java.sql.Connection adaptor. Correct implementation in this case would help to adopt other connection pools in some way.
Note 3: If HikariCP unfolds not well then object pool library like https://github.com/apache/commons-pool should be found.
Settings
- client.connection_pool.minimal_idle - minimal number of idle connections. This is useful to make application ready for requests.
- client.connection_pool.max_size - max number of idle and in-use connection. This is useful to limit application from over-booking connections.
- client.connection_pool.idle_ttl - time to live for idle connection. This let to release connection that are not part of minimal idle amount needed.
Note: none options above should be propagated to underlying transport
Metrics
- connection_pool.active_connections - number of active connections
- connection_pool.idle_connections - number of idle connections