Недавно задавал тут вопрос, что после редеплоя начинает виснуть Tomcat (6.0.29).
Причем просто висеть -- без всяких ошибок где либо (даже в логах ничего нет).
Посоветовали добавить память -- все заработало.
Вот сейчас опять начал висеть, и опять, видимо, из-за нехватки памяти.
Отсюда вопросы:
1) почему не выкидывается хотя бы какой-нибудь OutOfMemoryException?
2) почему не срабатывает GC? Ведь приложение до этого работало, ну выгружай ты старое приложение, подчищай за ним память, и вперед!) Так вот нет, весь сервер просто начинает висеть!
Здравствуйте, Аноним, Вы писали:
А>Спасибо. Т.е. если вы предлагаете снимать логи, получается это только у меня так?
Именно виснет когда — с таким не сталкивался ни разу. А вот кидание OutOfMemoryException при редеплое — это практически штатное поведение .
Здравствуйте, Аноним, Вы писали:
А>Что-то мне кажется я все очень типично делаю, чтобы было такое неявное поведение.
Телепатов нет. Может у вас с логированием что не так и OOME в лог не попадают. Может у вас куча заполняется максимально, но не переполняется, в то же время GC перегружает CPU, пытаясь очистить кучу.
Подключаетесь из Visual VM. Ждете зависания. Смотрите обстановку.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
А>>Спасибо. Т.е. если вы предлагаете снимать логи, получается это только у меня так? E>Именно виснет когда — с таким не сталкивался ни разу. А вот кидание OutOfMemoryException при редеплое — это практически штатное поведение .
Какие варианты борьбы с этим "штатным" поведением?
Здравствуйте, vb-develop, Вы писали:
А>>>Спасибо. Т.е. если вы предлагаете снимать логи, получается это только у меня так? E>>Именно виснет когда — с таким не сталкивался ни разу. А вот кидание OutOfMemoryException при редеплое — это практически штатное поведение .
VD>Какие варианты борьбы с этим "штатным" поведением?
Здравствуйте, vb-develop, Вы писали:
VD>Какие варианты борьбы с этим "штатным" поведением?
Второй вариант это анализ кучи в поисках ответа на вопрос почему предыдущий экземпляр приложения из неё не выгрузился.
Здравствуйте, vb-develop, Вы писали:
VD>Какие варианты борьбы с этим "штатным" поведением?
У меня только один. Деплоить следующим образом:
1) Стоп томката;
2) Деплой варника путем копирования;
3) Старт томката.
Других рецептов я не знаю.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, vb-develop, Вы писали:
VD>>Какие варианты борьбы с этим "штатным" поведением? B>Второй вариант это анализ кучи в поисках ответа на вопрос почему предыдущий экземпляр приложения из неё не выгрузился.
Много раз ресерчил этот вопрос, ни разу не удавалось довести до конца на более-менее объемных проектах. Хотелось бы поглубже разобраться с этим вопросом.
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, vb-develop, Вы писали:
А>>>>Спасибо. Т.е. если вы предлагаете снимать логи, получается это только у меня так? E>>>Именно виснет когда — с таким не сталкивался ни разу. А вот кидание OutOfMemoryException при редеплое — это практически штатное поведение .
VD>>Какие варианты борьбы с этим "штатным" поведением?
GIV>перезагрузка
Здравствуйте, vb-develop, Вы писали:
VD>Много раз ресерчил этот вопрос, ни разу не удавалось довести до конца на более-менее объемных проектах. Хотелось бы поглубже разобраться с этим вопросом.
Основная проблемы утечки памяти при редеплоее это переполнение PermGen
В PermGen живут загруженые классы. При редеплоее, старые классы не выгружаются и занимают PermGen вместе с новыми.
Старые классы не выгружаются из PermGen потому что их экземпляры всё ещё где-то используются. (Банальный вариант disable class GC не рассматриваем)
Где могут жить экземпляры классов старой версии приложения?
— Tomcat. Это маловероятно, но возможно. Например объект помещается в HttpSession. По логике, конечно, томкат должен сессию сериализовать и десериализовать при редеплоее. Уверен что он так и делает. Так что это только для иллюстрации.
— Другие библиотеки из Shared/Common. Т.е. эта библиотека загружена общим загрузчиком. Где-то она у себя хранит ссылку на какой-то объект. А этот объект реализован классом из вашего приложения.
— Потоки, запущеные вашим приложением.
Простейший способ, с которого можно начать, это задеплоить приложение. Прогнать на тестах. Раздеплоить. Подключится через Visual VM. Вызвать System.gc() (есть полезная опция, которая делает так чтобы System.gc() вызвал сборку классов именно в PermGen). Снять дамп кучи. Анализировать объекты, которые остались от вашего приложения и смотреть как они связаны с GC Roots.
Здравствуйте, vb-develop, Вы писали:
А>>>>>Спасибо. Т.е. если вы предлагаете снимать логи, получается это только у меня так? E>>>>Именно виснет когда — с таким не сталкивался ни разу. А вот кидание OutOfMemoryException при редеплое — это практически штатное поведение .
VD>>>Какие варианты борьбы с этим "штатным" поведением?
GIV>>перезагрузка
VD>Это не борьба, а workaround, не интересно.
Здравствуйте, GarryIV, Вы писали:
GIV>Да как не назови а других вариантов нет.
Томкат — контейнер сервлетов. Вот и пусть хорошо исполняет свое основное назначение — парсит запросы и отдает ответы, т.е. все связанное с обслуживанием протокола хттп. Не надо на него вешать что-то еще. Логика, сессии, аутентификация, подготовка ответа — этим пусть занимаются другие приложения (сервисы). Тогда приложения, которые деплоятся в Томкат, могут быть примитивными, из одного-двух сервлетов или jsp. Это просто прокси между хттп и внутренним миром сервера. Тогда редеплои будут быстры и безболезненны.
Здравствуйте, mselez, Вы писали:
GIV>>Да как не назови а других вариантов нет.
M>Томкат — контейнер сервлетов. Вот и пусть хорошо исполняет свое основное назначение — парсит запросы и отдает ответы, т.е. все связанное с обслуживанием протокола хттп. Не надо на него вешать что-то еще. Логика, сессии, аутентификация, подготовка ответа — этим пусть занимаются другие приложения (сервисы). Тогда приложения, которые деплоятся в Томкат, могут быть примитивными, из одного-двух сервлетов или jsp. Это просто прокси между хттп и внутренним миром сервера. Тогда редеплои будут быстры и безболезненны.
И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.
Я не вижу как твоя схема позволяет избежать перезапуска контейнера.
Как впрочем и не вижу смысла бороться с этим. Пока нет строгих гарантий полной выгрузки со стороны контейнера, нечего и изпользовать это ни для чего кроме локальноко девелопмента, да и то не в случае томката, который запускается молниеносно.
Здравствуйте, GarryIV, Вы писали:
M>>Томкат — контейнер сервлетов. Вот и пусть хорошо исполняет свое основное назначение — парсит запросы и отдает ответы, т.е. все связанное с обслуживанием протокола хттп. Не надо на него вешать что-то еще. Логика, сессии, аутентификация, подготовка ответа — этим пусть занимаются другие приложения (сервисы). Тогда приложения, которые деплоятся в Томкат, могут быть примитивными, из одного-двух сервлетов или jsp. Это просто прокси между хттп и внутренним миром сервера. Тогда редеплои будут быстры и безболезненны.
GIV>И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.
А почему для генерации HTML нужен Томкат? Эти UI фреймворки вне Томката не функционируют? Я просто не в курсе.
На мой взгляд вся эта практика по встраиванию в веб сервер многочисленных фреймворков сомнительна. Уже пора его (веб сервер) оставить в покое. Ведь редеплоймент "на лету" — это то, чем занимается OSGi. А Томкат это умел всегда. И на простых приложениях это прекрасно работает. А вев-приложения усложняются и теперь тут уже OSGi оказывается нужен. Но на серверной стороне есть же альтернатива в виде SOA, grid, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.
Здравствуйте, GarryIV, Вы писали:
GIV>И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.
Даже если для реализации сервиса опять нужен Томкат, то перезапуск отдельного сервиса, как правило, не влияет сильно на всю систему.
Здравствуйте, mselez, Вы писали:
M>>>Томкат — контейнер сервлетов. Вот и пусть хорошо исполняет свое основное назначение — парсит запросы и отдает ответы, т.е. все связанное с обслуживанием протокола хттп. Не надо на него вешать что-то еще. Логика, сессии, аутентификация, подготовка ответа — этим пусть занимаются другие приложения (сервисы). Тогда приложения, которые деплоятся в Томкат, могут быть примитивными, из одного-двух сервлетов или jsp. Это просто прокси между хттп и внутренним миром сервера. Тогда редеплои будут быстры и безболезненны.
GIV>>И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.
M>А почему для генерации HTML нужен Томкат? Эти UI фреймворки вне Томката не функционируют? Я просто не в курсе.
Да, UI фреймворкам нужен контейнер. ServletRequest, ServletResponce и тд и тп.
M>На мой взгляд вся эта практика по встраиванию в веб сервер многочисленных фреймворков сомнительна. Уже пора его (веб сервер) оставить в покое. Ведь редеплоймент "на лету" — это то, чем занимается OSGi. А Томкат это умел всегда. И на простых приложениях это прекрасно работает. А вев-приложения усложняются и теперь тут уже OSGi оказывается нужен. Но на серверной стороне есть же альтернатива в виде SOA, grid, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.
Может быть распределенным и должно быть распределенным — две большие разницы. Массе приложений распределенность не нужна.
.
