Подключение пула «Утечка» в разработке.Может ли это быть из-за настройки теста JUnit? - PullRequest
Новая
       27

Подключение пула «Утечка» в разработке.Может ли это быть из-за настройки теста JUnit?

1 голос
/ 10 марта 2011

Я пытаюсь отследить «утечку» пула соединений с базой данных в процессе разработки, и мне интересно, является ли это результатом того, как настроены модульные тесты. Что-то захватывает соединения с базой данных из пула Glassfish и не закрывает их по окончании. В конце концов, максимальное количество подключений к пулу израсходовано, и приложение не может получить новые подключения к базе данных.

Наши тесты JUnit получают соединение из пула в методе setUp (), а затем закрывают это соединение в методе tearDown (). Можем ли мы быть уверены, что метод tearDown () ВСЕГДА будет работать? Если возникает необработанное исключение, можно ли обойти метод tearDown ()?

Какие-нибудь другие идеи о том, что мы должны искать?

Следует отметить, что мы используем Jakarta Cactus для запуска этих модульных тестов на сервере приложений Glassfish.

Ответы [ 3 ]

1 голос
/ 11 марта 2011

Одно предложение предотвратить и сообщить об утечке соединения с базой данных:

Сначала выясните объем каждого соединения.

Например, для многих веб-приложений требуется соединение в объеме запроса.

С определенными областями все, что вам нужно сделать, это закрыть соединение детерминированным способом, сделав это в конце жизненного цикла области действия.

Один из способов утверждать, что соединение с базой данных всегда закрыто в веб-приложении, - создать фильтр сервлета, который будет получать соединение при поступлении запроса и закрывать соединение при отправке ответа. Соединение можно передать от фильтра к другим объектам, поместив его в переменную ThreadLocal.

Другой пример области действия - когда для транзакции требуется соединение. Возможно, вы захотите использовать шаблон Execute Around Method , чтобы получить соединение до начала области и закрыть его в конце детерминированным способом.

Если вы реализуете любую из этих идей, вы можете даже записать, какие соединения не были закрыты, прежде чем закрывать ее, чтобы помочь идентифицировать утечку.

Удачи, надеюсь, это поможет, пожалуйста, дайте мне знать иначе.

Обновление:

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

В моей среде я использовал tomcat с конфигурацией источника данных JNDI следующим образом: 

  <Resource auth="Container"
       name="jdbc/APP_NAME"
       username="user"
       password="password"
       url="jdbc:oracle:thin:@server.domain:1521:development"    
       type="javax.sql.DataSource"
       driverClassName="oracle.jdbc.driver.OracleDriver"

       maxIdle="10"
       maxWait="5000"
       maxActive="10"
       validationQuery="select 1 from dual"
       validationInterval="30000"
       testOnBorrow="true"
       testOnReturn="false"
       testWhileIdle="true"
       timeBetweenEvictionRunsMillis="5000"
       numTestsPerEvictionRun="3"
       minEvictableIdleTimeMillis="30000"


 <!-- These 3 settings saved me hours of headache -->

 logAbandoned="true" <!-- Will report the stacktrace of the faulty code --> 

 removeAbandoned="true" <!-- Will remedy the connection starvation while leaky code is not fixed-->

 removeAbandonedTimeout="60"<!-- Interval for fixing connection starvation while leaky code is not fixed-->

 />

См .: Конфигурация Apache DBCP

1 голос
/ 10 марта 2011

Соединение возвращается в пул, когда

  1. Соединение возвращается в пул, когда вы прагматично закрываете его (наконец, блокируете!)
  2. Полная сборка мусора
  3. Когда процесс Java завершается (остановка сервера, завершение единичного цикла)

Короче говоря, маловероятно, что ваши проблемы с пулами вызваны выполнением юнит-тестов.

0 голосов
/ 10 марта 2011

Я никогда не видел, чтобы tearDown пропускался, ЕСЛИ это правильный tearDown (правильный метод signatur или аннотация в зависимости от версии JUnit)

Но: Вы можете пропустить части tearDown, когда исключение выдается внутри tearDown.

Я бы проверил вашу теорию, запустив TestSuite и наблюдая за пулом соединений. Звучит довольно легко для меня.

...