Research background:

Establishing a database connection is a relatively expensive operation (at least for OLTP). Not only does it need to establish a TCP connection, it also needs to perform connection authentication operations, so the client usually saves the database connection in the connection pool for reuse. The connection pool maintains long connections to the elastic database (JED). By default, the elastic database will not actively close the client connection (unless an error is reported), but generally there will be load balancing agents between the client and the elastic database. They are usually used to save connection resources. After the connection is idle for 10 minutes, it will actively clean up the connection and release useless connection resources. As a result, some users' connection pool probing parameters are improperly configured, and then they get invalid connections. The client will report the following error:

Based on the above background, we conducted a research on the functions related to connection pool detection and activity of common versions of connection pools commonly used in Java applications, and provided JED configuration templates for each version. Currently, the commonly used connection pool versions are as follows:

HikariCP 3.2.0、 3.4.5、4.0.3

DRUID 1.1.10、1.1.9、1.0.9

DBCP 1.4 、2.2.0、2.1.1

HikariCP

In our first chapter, let’s introduce the content related to HikariCP connection pool detection:

The HikariCP connection pool will first check the status of the connection object when it needs to allocate the connection object to the application. To detect whether a connection is available, the connection pool calls isConnectionAlivemethods. If the connection object is available, the connection pool will allocate the connection object to the application; if the connection object is not available, the connection pool will create a new connection object and allocate the new connection object to the application.

Therefore, when the connection object of the HikariCP connection pool fails, the connection pool will only output a warning message in the log. It is recommended to shorten the maximum lifetime of the connection object (`maxLifetime`). However, this will not affect the normal execution of the program, because the connection pool will automatically recreate a new connection object and allocate it to the application. Therefore, applications can continue to use connection objects in the connection pool without being affected by stale connections.

Although when using the HikariCP connection pool, if the connection probe is not configured, the application will not report an error when it gets an invalid connection, but when the application needs to execute SQL, it may encounter an invalid connection, which requires re-establishing the connection. Added additional performance overhead. This does not take full advantage of the connection pool, because the main purpose of the connection pool is to improve the performance and scalability of the application by reusing connection objects.

In order to maximize the value of the connection pool, let's take a look at the content related to HikariCP probing, and see how to use the relevant probing parameters to use the connection pool more efficiently.

The following are related parameters common to HikariCP detection:

parameter name	illustrate	Defaults
minimumIdle	The minimum number of idle connections maintained by the connection pool	5
maximumPoolSize	The maximum number of connections that can be accommodated in the connection pool	10
maxLifetime	This parameter is used to control the maximum life cycle of the connection in the connection pool. When the established connection time exceeds this parameter, it will be destroyed in the idle state.	1800000 (30 minutes)
idleTimeout	This parameter is used to control the idle time of the connection in the connection pool. If it is set to 8 minutes, the idle connection exceeding minimumIdle will be cleaned up every 8 minutes.	600000 (10 minutes)
connectionTestQuery	This parameter in lower versions will only execute the configured SQL before providing a connection from the pool. This parameter is applicable to the API that does not support JDBC4 Connection.isValid(), and it is recommended not to configure the driver that supports JDBC4 or above.	none
keepaliveTime	This attribute is to prevent the underlying network infrastructure from disconnecting overtime, periodically verify the validity of the connection, and remove it from the connection pool if the connection fails. This value must be less than the maxLifetime value. 4. The new parameters introduced in version 0.1 and above can be combined with the connectionTestQuery parameter to test.	0 (disabled)

The detection code of the HikariCP connection pool is as follows. It can be seen that during probing, the connection pool will decide whether to use the JDBC API for probing according to the value of the isUseJdbc4Validation attribute. The value of the isUseJdbc4Validation attribute is assigned according to whether the connectionTestQuery attribute is empty when the data source is initialized. If the connectionTestQuery attribute is empty and the value of the isUseJdbc4Validation attribute is true, the connection pool will use the JDBC API for detection. Therefore, in JDBC 4.0 and above, it is not recommended to configure the connectionTestQuery attribute for probing, because this will affect the efficiency of probing.

In lower versions of HikariCP, the connection cannot be kept alive, and the validity of the connection can only be verified every time the connection is obtained. In version 4.0.1, the keepaliveTime parameter is introduced, which can detect the connection regularly. Therefore, in order to avoid getting closed connections, in the lower versions, you can only adjust the maxLifetime parameter to less than 10 minutes to completely avoid getting closed connections from the gateway. In version 4.0.1 and above, you can use the keepaliveTime parameter in conjunction with the connectionTestQuery parameter to perform connection detection, so that detection can be performed before the connection is obtained. This improves the reliability and stability of the connection, preventing applications from encountering invalid connections.

After configuring keepaliveTime, we can see that the detection log will be printed out every time the configured time is reached.

Therefore, it is recommended to use a version above 4.0.1 that supports keepaliveTime for applications that use HikariCP online.

JED configuration template:

HikariCP3.2.0

spring.datasource.hikari.minimumIdle=5
spring.datasource.hikari.maximumPoolSize=10
spring.datasource.hikari.maxLifetime=540000
spring.datasource.hikari.idleTimeout=480000
#JDBC4以上的版本不建议配置connectionTestQuery
spring.datasource.hikari.connectionTestQuery=select 1

In the lower version, it is mainly guaranteed that the maxLifetime is less than 10 minutes to completely avoid getting the connection that the gateway has closed, but it may cause frequent creation and destruction of connections, so it is recommended to use a version that supports keepaliveTime above 4.0.1.

HikariCP3.4.5

Same as version 3.2.0.

HikariCP4.0.3

spring.datasource.hikari.minimumIdle=5
spring.datasource.hikari.maximumPoolSize=10
spring.datasource.hikari.maxLifetime=1800000
spring.datasource.hikari.idleTimeout=600000
#JDBC4以上的版本不建议配置connectionTestQuery
spring.datasource.hikari.connectionTestQuery=select 1
spring.datasource.hikari.keepaliveTime=300000

In versions above 4.0.1, you can set the keepaliveTime parameter to less than 10 minutes to detect the connection, so as to avoid getting the connection closed by the gateway, and the maxLifetime time can be extended to avoid frequent creation and destruction of connections.

Reference document: https://github.com/brettwooldridge/HikariCP#readme

Author: Jingdong Retail Wang Leixin

Source: Reprinted by JD Cloud developer community, please indicate the source

Elastic database connection pool detection strategy research (1) - HikariCP | JD Cloud technical team