При повторном развертывании Tomcat происходит сбой при использовании Teamcity

Question

Я использую Teamcity для запуска CI, который прекрасно работает, за исключением одного: когда мое веб-приложение развертывается в веб-контейнере (Tomcat 5.5) после нескольких раз, когда Tomcat не хватает памяти. Это то, что вы видите и в разработке, но это не такая большая проблема, так как вы можете перезапустить вручную любым способом - с помощью CI все происходит автоматически, что делает его действительно раздражающим.

Я попытался настроить Teamcity таким образом, чтобы он перезапускал Tomcat при каждом развертывании, но затем я столкнулся с другой проблемой - стартовый скрипт Tomcat просто зависает при вызове из ant (то есть он запускает Tomcat просто отлично, но потом не идет дальше в процессе сборки).

Кто-нибудь с подобной настройкой Teamcity-Tomcat?

Answer 1

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

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

Answer 2

Полагаю, что эта проблема не относится к TeamCity.

Как вы вызываете скрипт запуска Tomcat из Ant?

Если вы используете задачу «exec», вам, вероятно, нужно установить для атрибута «spawn» значение true, чтобы он порождал Tomcat в другом процессе. В противном случае Ant ожидает завершения процесса, прежде чем продолжить.

В наших развертываниях у нас есть скрипт, который проверяет уровни permgen и (опционально) перезапускает Tomcat, если permgen слишком высок.

Answer 3

У нас была точно такая же проблема, и, как отмечает Марк Робинсон, это связано с тем, что классы не собирают мусор.

Особой проблемой, с которой мы столкнулись, было множество загружаемых статических материалов: log4j, контексты Spring, помещенные в статические глобальные переменные, и другие библиотеки классов, создавшие статические экземпляры или синглтоны.

Можно было отследить многие из них с помощью профилировщика, а затем явно заняться очисткой ресурсов в методе destroy() сервлета. Хотя это не полностью решило проблему, это действительно помогло решить некоторые проблемы.

В конце мы добавили дополнительную пару целей ant для остановки и запуска Tomcat и включили в них процесс сборки. YMMV.