объект соединения из пула соединений hikaricp

Я использую hikaricp (это, вероятно, применимо и к любому другому пулу соединений с базой данных). У меня есть класс DBPool, в котором я создаю экземпляр HikariDataSource (используя объект HikariConfig). Я использую идиому ленивого держателя для этого DBPool, чтобы ограничить один экземпляр пула на виртуальную машину. Однако, как только вы получите ссылку на пул, вы можете получить объект Connection (без каких-либо дополнительных проверок блокировки/синхронизации/семафора), так как я думал, что пул соединений позаботится об ограничениях моего объекта соединения. Каждый раз, когда я получаю ссылку на соединение через DBPool, я вызываю close для соединения/preparedstatement/resultset. Я мог бы попробовать попробовать ресурсы, если это вызывает проблему. В логах наблюдаю следующее:

2014-09-14 18:53:25,302 WARN c.z.h.p.LeakTask [Hikari Housekeeping Timer (pool testHikariCp)] Connection leak detection triggered, stack trace follows java.lang.Exception
        at com.akkadian.db.DBConnPool.getConnection(DBConnPool.java:67)
        at models.tester.storeload.testAlertLogStoreLoad.loadAll(testAlertChk.java:101)
        at com.testLib.map.MapStoreWrapper.loadAll(MapStoreWrapper.java:131)
        at com.testLib.map.mapstore.AbstractMapDataStore.loadAll(AbstractMapDataStore.java:40)
        at com.testLib.map.BasicRecordStoreLoader$MapLoadAllTask.run(BasicRecordStoreLoader.java:340)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at com.testLib.util.executor.CompletableFutureTask.run(CompletableFutureTask.java:57)
        at com.testLib.util.executor.CachedExecutorServiceDelegate$Worker.run(CachedExecutorServiceDelegate.java:209)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
        at com.testLib.util.executor.testLibManagedThread.executeRun(testLibManagedThread.java:76)
        at com.testLib.util.executor.testLibManagedThread.run(testLibManagedThread.java:92)

Я увеличил время ожидания соединения и установил порог утечки следующим образом:

     hikariConfig.setConnectionTimeout(90000); 
     hikariConfig.setLeakDetectionThreshold(10000); 

Я также увеличил размер пула, хотя это было рекомендовано не делать — мне пришлось тестировать различные варианты, так как я получал тайм-ауты соединения с базой данных.


person Community    schedule 14.09.2014    source источник


Ответы (1)


Убедитесь, что вы действительно освобождаете соединение обратно в пул? Можете ли вы использовать попытку с ресурсами (в дополнение к увеличению порога, как упомянул Бретт):

try (Connection conn = DBConnectionPool.getConnection(); 
        PreparedStatement ps = conn.prepareStatement(preparedQuery);) {

и набор результатов (поскольку некоторые драйверы/базы данных могут не очищать набор результатов при очистке соединения, хотя я не уверен, что это все еще действительно для новых драйверов/баз данных, но я не уверен, что вы используете):

попробуйте (ResultSet rs = ps.executeQuery();) {

Увеличьте порог обнаружения утечек, если это необходимо, хотя я думаю, что если вам придется сделать его слишком большим, у вас есть проблема, которую необходимо исправить.

person ali haider    schedule 16.09.2014