2016-10-12 1 views
0

Я использую HikariCP в веб-приложения и вдруг, я получаю это исключение:HikariCP обнаруживает connectionleak хотя все мой код имеет вызов закрытым способом

[Hikari housekeeper (pool HikariPool-0)] WARN com.zaxxer.hikari.pool.ProxyLeakTask - Connection leak detection triggered for connection [email protected], stack trace follows 

java.lang.Exception : Обнаружена явная обнаруженная утечка связи

Я уже проверил и убедился, что все мои коды sql имеют вызов метода закрытия.

Вот мой HikariConfig:

private HikariConfig hikariConfig() { 
    HikariConfig config = new HikariConfig(); 
    config.setDriverClassName(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(40); 
    config.setMinimumIdle(0); 
    config.setMaxLifetime(TimeUnit.MINUTES.toMillis(2)); // 120 seconds max life time 
    config.setIdleTimeout(TimeUnit.MINUTES.toMillis(1)); // minutes 
    config.setConnectionTimeout(TimeUnit.MINUTES.toMillis(5)); // millis 
    config.setConnectionTestQuery("/* ping */ SELECT 1"); 

    return config; 
} 

вот как мои запросы выглядеть следующим образом:

public ArrayList<LocationType> getLocationTypes() { 
    ArrayList<LocationType> locationTypes = new ArrayList<>(); 
    Connection connection = null; 
    PreparedStatement pstmt = null; 
    ResultSet resultSet = null; 

    try { 
     connection = DataSource.getInstance().getConnection(); 

     pstmt = connection.prepareStatement("SELECT\n" + 
       " location_type_id,\n" + 
       " location_type_name\n" + 
       "FROM tablename;"); 

     resultSet = pstmt.executeQuery(); 

     while (resultSet.next()) { 
      locationTypes.add(new LocationType(resultSet.getInt("location_type_id"), resultSet.getString("location_type_name"))); 
     } 

    } catch (Exception e) { 
     e.printStackTrace(); 
    } finally { 
     if (resultSet != null) 
      try { 
       resultSet.close(); 
      } catch (SQLException e) { 
      } 

     if (pstmt != null) 
      try { 
       pstmt.close(); 
      } catch (SQLException e) { 
      } 

     if (connection != null) 
      try { 
       connection.close(); 
      } catch (SQLException e) { 
      } 
    } 
    return locationTypes; 
} 

Я уже пытался увеличения connectionLeakDetection, макс подключения и минимум простоя, но ничего из этого не решен вопрос ,

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

Я заметил, что некоторые длинные запросы в моем коде теперь обнаруживаются как утечка соединения, хотя я не называю их методами. Надеюсь, вы, ребята, могли бы помочь.

Это трассировки стека:

at com..database.DataSource.getConnection(DataSource.java:148) 
at com.database.databaseServices.MileageReportService.MileageService.getMonthlySummaryBySID(MileageService.java:27) 
at com.views.reports.mileage.MileageReport.lambda$generateReport$61446b05$1(MileageReport.java:103) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:498) 

Единственная линия эта линия - MileageService.java:27, мой запрос к БД и имеет близкое утверждение в ее наконец позвонить.

+0

версию Hikari CP вы используете? –

+0

также можете ли вы поделиться стеком, который следует за строкой журнала, которую вы опубликовали? – Ivan

+0

Я использовал 2.4.3. Я просто обновил сегодня до 2.5.1, но я все равно получаю то же исключение. – JRojo

ответ

0

Обновите последнюю версию HikariCP.

HikariCP сообщает о связи как утечку, потому что время, затраченное на заимствование до закрытия, превышает указанное значение LeakDetectionThreshold.

Версия 2.4.9 и более поздняя версия регистрируются, если соединение возвращается после сообщения об утечке.

Кроме того, глядя на вашей конфигурации, я бы настроить свойства следующим образом (первые 4 до 1 минуты и последний до 5):

config.setLeakDetectionThreshold(TimeUnit.MINUTES.toMillis(1)); 
config.setConnectionTimeout(TimeUnit.MINUTES.toMillis(1)); 
config.setValidationTimeout(TimeUnit.MINUTES.toMillis(1)); 
config.setIdleTimeout(TimeUnit.MINUTES.toMillis(1)); 

config.setMaxLifetime(TimeUnit.MINUTES.toMillis(5)); 

HTH

+0

Привет, Нитин, спасибо за ваш ответ. Я обновил свой hikariconfig с тем, который вы предложили, но исключение все еще происходит. В настоящее время я использую hikari 2.5.1. – JRojo

+0

после ожидания пары минут, вроде 5 или около того, я увидел журналы, которые соединение вернулось в пул.Несмотря на то, что время выполнения моего запроса не занимает много времени, я не уверен, почему это займет некоторое время после его реализации в моем Java-коде. – JRojo

+0

log также показывает идентификатор соединения. вероятно, выставлять отладочные заявления вокруг запроса, который, по вашему мнению, занимает второе место, а не 5 мин. – Nitin

Смежные вопросы