How do I mitigate Connection leak triggered for connection com.mysql.jdbc.JDBC4Connection@11d08960,

Question

I have an mqtt client getting request subscribing from topics, and then I give it to threadpool of fixed size 50. Im using hikaricp 2.4.2 for DB Pooling MySQL database.

Im currently using 2.4.2 and this is my setup

    HikariConfig config = new HikariConfig();
    config.setDataSourceClassName(CLASS_FOR_NAME);
    config.setJdbcUrl(HOST);
    config.setUsername(USER);
    config.setPassword(PASS);
    config.addDataSourceProperty("cachePrepStmts", "true");
    config.addDataSourceProperty("prepStmtCacheSize", "250");
    config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048");
    config.setLeakDetectionThreshold(TimeUnit.SECONDS.toMillis(30));
    config.setValidationTimeout(TimeUnit.MINUTES.toMillis(1));
    config.setMaximumPoolSize(10);
    config.setMinimumIdle(0);
    config.setMaxLifetime(TimeUnit.MINUTES.toMillis(2)); // 120 seconds 
    config.setIdleTimeout(TimeUnit.MINUTES.toMillis(1)); // minutes
    config.setConnectionTimeout(TimeUnit.MINUTES.toMillis(5)); 
    config.setConnectionTestQuery("/* ping */ SELECT 1");

Heres the full log message :

WARNLOG:

811439 [Hikari housekeeper (pool HikariPool-0)] WARN com.zaxxer.hikari.pool.ProxyLeakTask - Connection leak detection triggered for connection com.mysql.jdbc.JDBC4Connection@11d0896, stack trace follows java.lang.Exception: Apparent connection leak detected at com.hcpdatabase.DataSource.getConnection(DataSource.java:69) at com.database.AccessDatabase.create_alert(AccessDatabase.java:3849) at com.runnable.StartTaskRunnable2.execute(StartTaskRunnable2.java:78)

Is this normal ? do i have to catch this?

Answer 1

As I have reviewed my codes over and over again. I came to realize that I was barking at the wrong tree, Seems like hikari is very reliable when it comes to connection leak. The problem is when amazon aws ec2 instance is stealing some of my cpu and is even greater than what i thought. So after the cpu goes up 99%, Connection leak is detected even though my codes clearly closed it in finally block. So the problem lies with the machine.

I thank you for all who participated to answer.

Answer 2

walk thru the code with 'stack trace' and it would lead you to un-closed connection or the connection that takes longer than threshold.