Цикл очистки пула HikariCP на jenkins

Привет, сообщество stackoverflow,

У меня очень неприятная проблема с моими дженкинсами и хикаричпом.

Чтобы рассмотреть проблему в перспективе: у меня есть приложение для весенней загрузки, которое использует hikariDataSource. Он отлично работает во время разработки, и все тесты запускаются локально без каких-либо проблем. Но если тот же проект выполняется в jenkins как задание ci, которое делает то же самое, что и я на своей машине разработки, он на некоторое время застревает при очистке пула соединений:

2015-08-28 15: 51: 52.090 ОТЛАДКА 8234 --- [l HikariPool-0)] com.zaxxer.hikari.pool.HikariPool: Перед очисткой пула статистика HikariPool-0 (всего = 10, активно = 0, простаивает = 10, ожидание = 0) 2015-08-28 15:51: 52.091 DEBUG 8234 --- [l HikariPool-0)] com.zaxxer.hikari.pool.HikariPool: После очистки пула Статистика HikariPool-0 (всего = 10, active = 0, idle = 10, wait = 0) 2015-08-28 15:52: 22.090 DEBUG 8234 --- [l HikariPool-0)] com.zaxxer.hikari.pool.HikariPool: перед очисткой пула HikariPool-0 stats (всего = 10, активно = 0, простаивает = 10, ожидание = 0) 2015-08-28 15: 52: 22.091 ОТЛАДКА 8234 --- [l HikariPool-0)] com.zaxxer.hikari.pool.HikariPool: После очистки пула статистика HikariPool-0 (всего = 10, активно = 0, простаивает = 10, ожидание = 0)

Это то, что я получил за пару минут, а затем тест продолжается.

В тестовой среде я использую базу данных h2 в памяти.

После пары часов поиска в google и github я ни на йоту не приблизился к решению.

Я использую Spring Boot 1.2.5, HikariCP 2.4.1, Hibernate 4.3.10.final.

Конфигурация проекта весенней загрузки основана на конфигурации jhipster.

Большое спасибо за вашу помощь и дополнительную информацию для решения проблемы.


jenkins spring-boot java hibernate hikaricp
person conscience    schedule 28.08.2015    source источник
comment
Вы уверены, что ваша тестовая система отключает HikariDataSource? Если вы используете конфигурацию Spring, где-то должно быть свойство destroy, связанное с методом HikariDataSource.close (). Может быть, что-то вроде this?   -  person brettw    schedule 28.08.2015
comment
Спасибо за Ваш ответ. Я не уверен, что вы имеете в виду. Конфигурация My DataSource действительно вызывает метод закрытия при завершении работы. Вы имели в виду, что он вызван рано?   -  person conscience    schedule 28.08.2015

Ответы (2)


arrow_upward
0
arrow_downward

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

Наличие этих журналов не означает, что HikariCP завис. Судя по всему этому журналу, соединения вообще не используются.

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

person brettw    schedule 29.08.2015
comment
Спасибо, brettw. Я проверю это в понедельник и отправлю свои выводы. - person conscience; 30.08.2015

arrow_upward
0
arrow_downward

благодаря @brettw я смог решить проблему. Журналы действительно привели меня в неверном направлении, к мысли, что хикарич сделал что-то не так.

Основной причиной наших длительных сборок был источник энтропии, который используется встроенным tomcat для создания экземпляра SecureRandom.

Согласно этому сообщению: победило приложение Spring Boot Actuator 't start on Ubuntu VPS, мы попытались установить источник на /dev/./urandom, что также не работает.

В итоге мы установили haveged, как предложил @starmer. Теперь все работает нормально. Строится безумно быстро.

Большое спасибо @brettw за то, что указал мне в правильном направлении!

person conscience    schedule 31.08.2015