Possibly consider using a shorter maxLifetime value - hikari connection pool spring boot

Question

After starting my SpringBoot application, getting an exception on few minutes of the server startup. Did not use any HikariPool Configuration externally, Spring Boot is using HikariPool by default This is the error I am getting in the console:

2020-02-20 03:16:23 - HikariPool-4 - Failed to validate connection 
com.mysql.cj.jdbc.ConnectionImpl@4c4180c8 (No operations allowed after connection closed.). 
Possibly consider using a shorter maxLifetime value.
2020-02-20 03:16:28 - HikariPool-4 - Failed to validate connection 
com.mysql.cj.jdbc.ConnectionImpl@679c2f50 (No operations allowed after connection closed.). 
Possibly consider using a shorter maxLifetime value.
2020-02-20 03:16:33 - HikariPool-4 - Failed to validate connection 
com.mysql.cj.jdbc.ConnectionImpl@16083061 (No operations allowed after connection closed.). 
Possibly consider using a shorter maxLifetime value.
2020-02-20 03:16:38 - HikariPool-4 - Failed to validate connection 
com.mysql.cj.jdbc.ConnectionImpl@4fcaf421 (No operations allowed after connection closed.). 
Possibly consider using a shorter maxLifetime value.
2020-02-20 03:16:43 - HikariPool-4 - Failed to validate connection 
com.mysql.cj.jdbc.ConnectionImpl@33df5d54 (No operations allowed after connection closed.). 
Possibly consider using a shorter maxLifetime value.
2020-02-20 03:16:48 - HikariPool-4 - Failed to validate connection 
com.mysql.cj.jdbc.ConnectionImpl@373d288c (No operations allowed after connection closed.). 
Possibly consider using a shorter maxLifetime value.
2020-02-20 03:16:48 - SQL Error: 0, SQLState: 08003
2020-02-20 03:16:48 - HikariPool-4 - Connection is not available, request timed out after 
30156ms.
2020-02-20 03:16:48 - No operations allowed after connection closed.
2020-02-20 03:16:48 - Servlet.service() for servlet [dispatcherServlet] in context with path 
[] threw exception [Request processing failed; nested exception is 
org.springframework.dao.DataAccessResourceFailureException: Unable to acquire JDBC 
Connection; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to 
acquire JDBC Connection] with root cause

Solution 1

The problem is that the default value of the spring.datasource.hikari.maxLifetime property (default of 30 minutes, https://github.com/brettwooldridge/HikariCP#configuration-knobs-baby) is higher than the database's wait_timeout, 10 minutes in my case.
So you have two options, either decrease the hikari.maxLifetime below 10 minutes, or increase the database's wait_timeout property.

Solution 2

You can set the value as below in the application.properties file

spring.datasource.hikari.maxLifeTime : 600000 #10 minutes wait time

Comments

[yeahseol]

What is root cause?

[Sanjog]

Here's the complete exception stack:

[Abhishek Aggarwal]

Do you know that is the property against which we have to set that value?

[GiovanyMoreno]

spring.datasource.hikari.max-lifetime=600000 (in milliseconds)

[Canatto Filipe]

I did a test using wait_timeout = 300 (5 minutes), and max-lifetime = 600000 (10 minutes). However I was not able to get this error. Do you know why ?

[Vikas Tawniya]

@CanattoFilipe The error occurs when the application tries to interact with DB with the old pool of connection(older than DB wait_timeout) which it assumes to be live. So I think you should try simulating that.

[M. Deinum]

You don;t need to define the bean, just provide the proper properties in your application.properties suggesting to fix this by replacing the bean isn't the proper solution.

[Magno C]

RAVI SHANKAR's answer is best because it tell us "do this to solve" instead "find out how to do this to solve"

[Levent Divilioglu]

@M.Deinum However making people aware of the beans does not harm. I still find it useful but I agree that the best practice for configuration is to use properties file.

[M. Deinum]

The problem with this is that when you define the bean, without further/proper knowledgeee, in Spring Boot parts of the auto configuration back off. Which often lead to surprising results for users without the proper knowledge.