Есть ли простой способ заставить Apache Tomcat автоматически перезагружаться после развертывания?

Question

В нашем проекте Cruise Control используется как для сборки, так и для оперативного развертывания веб-приложения на удаленном сервере (через FTP), на котором запущен Tomcat в виде файла .war. К сожалению, «горячие» развертывания не работают должным образом, поэтому мы перезагружаем Tomcat в ответ на каждое развертывание. Мы действительно хотели бы сделать это автоматически, очень похоже на саму сборку. Есть ли простой способ сделать это?

Примечание: обе машины работают под управлением Windows (я думаю, XP или сервер).

Примечание 2: Производительность на самом деле не имеет значения. Это интегрированная коробка.

Answer 1

Зарегистрирован ли tomcat как служба Windows?

Если это так, просто напишите сценарий .bat, используя netstart и netstop, и вызовите его как последний шаг процесса развертывания.

Answer 2

Если вы посмотрите на сценарии запуска и завершения работы tomcat .bat (или .sh) в каталоге bin, вы увидите, что они фактически запускают процесс Java для запуска tomcat или, в случае выключения, подключаются к отключению tomcats порт - смотрите server.xml в каталоге conf. Вы можете настроить задачу сборки ant так, чтобы она вызывала jar-файлы tomcat так же, как это делают сценарии.

Answer 3

если у вас регулярно запланированы сборки, вы можете легко поместить что-то в cron, например,

crontab -e

затем остановите кота, скажем, в 1:30

30 1 * * * ./path_to_tamcat/bin/catalina.sh stop

затем запустите его снова через 2 минуты

32 1 * * * ./path_to_tamcat/bin/catalina.sh start

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

Answer 4

Вы не дали много подробностей, почему ваши горячие развертывания "не работают должным образом", но если это на самом деле было вызвано тем, что ресурс в /WEB-INF/lib заблокирован (что не является редкой причиной; вы часто видите это с mail.jar API JavaMail), а затем просто установите для атрибута Context antiResourceLocking значение true. Вот пример того, как будет выглядеть /META-INF/context.xml веб-приложения:

<Context antiResourceLocking="true">
    <!-- Your stuff here. -->
</Context>

Answer 5

пополняемые = "истинный"

не включает повторное развертывание war-файлов (это будет работать автоматически), оно позволяет отслеживать изменения файлов в WEB-INF / classes и WEB-INF / lib, что, вероятно, не то, что вам нужно.

Большую часть времени, когда повторное развертывание war-файлов в Tomcat зависало, я мог отследить его до утечек из загрузчика классов, см. См. Утечки из загрузчика классов: страшная "java.lang.OutOfMemoryError: пространство PermGen" исключение

Answer 6

Какую версию tomcat вы используете? Что именно происходит, когда создается впечатление, что «горячее» развертывание не работает?

Answer 7

Мне кажется, что вы используете маленький менеджер развертывания Tomcat. У меня, по сути, нет опыта в этом, просто чтобы вы знали. Тем не менее, где я работаю, мы используем две настройки.

В файле server.xml контекст имеет атрибут reloadable = "true" .

Все, что нам нужно сделать, это поместить файл WAR в нужное место, и Tomcat распакует его и перезагрузит, без проблем.

Теперь, когда я посмотрел, в официальном справочнике по конфигурации 1010 * написано:

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

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

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

Я должен заметить, что время от времени все просто идет не так, как надо, и нам все равно приходится перезапускать Tomcat, но это относительно редко.

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

Другие случайные догадки:

1. Вы отправляете FTP прямо в окончательное местоположение WAR? Может быть, Tomcat просто пытается открыть его слишком рано?
2. Получаете ли вы какие-либо сообщения об ошибках? Может быть, это поможет вам отследить проблему?
3. Вы пробовали другие версии Tomcat (если они вам доступны)? Может быть, 5.5 не имеет проблемы (или 5.0, если вы используете 5.5)? Может быть, просто более новая редакция?