У меня проблемы с сервером приложений Tomcat. Прежде чем я смогу решить проблему с Java-приложением, мне нужно придумать сценарий оболочки cron для перезапуска сервера.
Я думал, что это будет несложная задача, но единственное осложнение заключается в том, что основная причина не позволяет Tomcat полностью завершаться после выполнения ./shutdown.sh. Процесс все еще открыт, когда я запускаю ps auwwx | grep java | grep org.apache.catalina.startup.Bootstrap
Я убиваю -9 процесс (да, это плохо, но пока все идет хорошо;)) и я могу перезапустить сервер правильно.
Я не эксперт по сценариям оболочки (или новичок в этом отношении), и мне нужна помощь с "опросом" в течение некоторого времени, пока приведенная выше команда ps не вернет null. После периода опроса я бы убил, а затем перезапустил.
Это приблизительный набросок сценария, который будет делать то, что вы хотите. Конечно, вам придется конкретизировать это, и вы можете изменить аргумент на sleep
(здесь показано пять секунд).
#!/bin/bash
while ps | grep | grep > /dev/null
do
sleep 5
done
kill
restart
При необходимости вы можете объединить два grep в один, используя регулярное выражение. Примечание: когда вы делаете такие вещи, вы можете иногда получать ложные срабатывания, когда grep
находит себя (хотя ваши два grep предотвращают это). Чтобы этого избежать, вы можете сделать grep [s]omething
который найдет "... something ...", но не "grep something" в выводе ps
.
Мы должны были решить именно эту проблему при разработке нашего продукта Tcat Server для поддержки надежных перезапусков.
Вы можете скачать Tcat Server и взглянуть на tcat6.sh, чтобы узнать, как мы это решили. Если у вас есть конкретные вопросы, пишите здесь.
Tcat Server - это на самом деле 100% ванильный Tomcat с дополнительными функциями для управления конфигурацией, развертывания и диагностики - хотелось бы, чтобы вы загрузили и посмотрели, соответствует ли он вашим потребностям. Его можно бесплатно использовать в разработке, и его можно загрузить с: http://www.mulesoft.com/download-tcat-server-enterprise-tomcat. Если вы не хотите использовать веб-консоль, вы можете использовать curl для вызова Tcat Server REST API для перезапуска.
Надеюсь это поможет.
Отказ от ответственности: я работаю в MuleSoft и активно участвую в Tcat Server.
То, что вы делаете, - это патч, который не позволяет должным образом обрабатывать исключения Java. Я понимаю, что хочу перезапустить, правда, да. Если это долгосрочный или производственный проект, мир станет лучше, если вы просто поймаете и обработаете ошибки.
(Tomcat умирает, если какие-либо ошибки возвращаются в стек вызовов.)
Серверы приложений, такие как Tomcat, не любят, если веб-приложения ведут себя неправильно (делают неприятные вещи с загрузчиками классов, утечки памяти, запускают не-демонические потоки и т. Д.), Поэтому они не могут должным образом завершиться, когда их попросят.
Во-первых, жесткий перезапуск Tomcat может быть «правильным» решением, позволяющим продолжать работу до тех пор, пока приложение не будет исправлено. Следующее, что нужно сделать, - это повысить уровень журнала и проверить файлы журнала на наличие опасных ошибок, таких как OutOfMemoryErrors и т. Д. Если вам повезет, веб-приложение использует ведение журнала и может указать, что оно делает.
Следующее, что нужно сделать, это прикрепить агент мониторинга (visualvm.dev.java.net отлично справляется) с экземпляром Tomcat. Вам необходимо включить JMX на стороне сервера, прежде чем вы сможете подключиться к нему удаленно. Если вы используете Suse Linux или что-то подобное, не забудьте указать имя хоста rmi сервера как системное свойство. Следите за потреблением памяти, снимайте дампы потоков при зависании серверов. Когда вы отправляете запрос на отключение с помощью shutdown.sh
и сервер не выключается правильно, возьмите дамп потока и посмотрите, какие потоки работают и в каком классе / методе они сейчас.
Если что-то не так с памятью, вы можете попробовать изменить настройки сборщика мусора для JVM или использовать другую JVM, например JRockit. Может помочь использование более агрессивного GC.
Другой способ - запретить приложению делать то, что оно делает неправильно - используйте диспетчер безопасности и настраивайте файл политики безопасности, пока приложение не заработает. Это может показать, что приложение делает что-то, чего не должно делать в первую очередь.