如何缓解因连接com.mysql.jdbc.JDBC4Connection@11d08960而触发的连接泄漏， [英] How do I mitigate Connection leak triggered for connection com.mysql.jdbc.JDBC4Connection@11d08960,

问题描述

我有一个mqtt客户端，该用户正在从主题中订阅请求， 然后将其提供给固定大小为50的线程池. 我将hikaricp 2.4.2用于数据库池MySQL数据库.

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.

我当前正在使用2.4.2，这是我的设置

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管家(池HikariPool-0)] WARN com.zaxxer.hikari.pool.ProxyLeakTask-连接泄漏检测 为连接com.mysql.jdbc.JDBC4Connection@11d0896触发，堆栈 跟踪java.lang.Exception之后:检测到明显的连接泄漏 在com.hcpdatabase.DataSource.getConnection(DataSource.java:69) 在com.database.AccessDatabase.create_alert(AccessDatabase.java:3849) 在com.runnable.StartTaskRunnable2.execute(StartTaskRunnable2.java:78)

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?

推荐答案

我已经一遍遍地检查了我的代码.我意识到我在错误的树上吠叫，当涉及到连接泄漏时，好像hikari似乎非常可靠.问题是，当Amazon AWS EC2实例窃取我的某些CPU时，甚至比我想的还要大.因此，在CPU上升99％之后，即使我的代码在finally块中将其明确关闭，也可以检测到连接泄漏.因此问题出在机器上.

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.

这篇关于如何缓解因连接com.mysql.jdbc.JDBC4Connection@11d08960而触发的连接泄漏，的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！