Недавно задавал тут вопрос, что после редеплоя начинает виснуть 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, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.
Может быть распределенным и должно быть распределенным — две большие разницы. Массе приложений распределенность не нужна.
Здравствуйте, mselez, Вы писали:
GIV>>И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.
M>Даже если для реализации сервиса опять нужен Томкат, то перезапуск отдельного сервиса, как правило, не влияет сильно на всю систему.
Ровно в той же степени как и перезапуск Томката с веб приложением внутри.
Здравствуйте, mselez, Вы писали:
M>А почему для генерации HTML нужен Томкат? Эти UI фреймворки вне Томката не функционируют? Я просто не в курсе.
Вобще конечно можно запустить и без томката, вопрос только зачем?
M>На мой взгляд вся эта практика по встраиванию в веб сервер многочисленных фреймворков сомнительна.
Ну все-таки это контейнер сервлетов, а не веб сервер. Поэтому его обязанности парсиньем запросов и отдачей ответов не ограничиваются. Фреймворки встраиваются не в томкат, а в аппликуху.
M>Уже пора его (веб сервер) оставить в покое. Ведь редеплоймент "на лету" — это то, чем занимается OSGi. А Томкат это умел всегда. И на простых приложениях это прекрасно работает.
Простые приложеня это парочка jsp? Так как если будет что-нибудь сложнее, то уже очень вероятно, что возникнут проблемы. Но мы то не о hello word говорим, правильно?
M>А вев-приложения усложняются и теперь тут уже OSGi оказывается нужен. Но на серверной стороне есть же альтернатива в виде SOA, grid, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.
Зачем здесь OSGi? Зачем SOA для средненькой веб аппликухи? Усложнить аппликуху на пустом месте ради хот редеплоя? Зачем разбивать на куски то, что по сути является единым целым и при этом, кроме усложнения кода не получить никакой выгоды? О каких плагинах к томкату идет речь? Вы говорите о фреймворках как о плагинах, и хотя стоит признать, что в чем то они между собой похожи, но фреймворк != плагин.
Здравствуйте, mselez, Вы писали:
M>Здравствуйте, GarryIV, Вы писали:
GIV>>И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.
M>Даже если для реализации сервиса опять нужен Томкат, то перезапуск отдельного сервиса, как правило, не влияет сильно на всю систему.
С таким же успехом можно томкат спрятать за Apache HTTP Server, и поднимать по одному томкату на каждое приложение.
Здравствуйте, vb-develop, Вы писали:
VD>С таким же успехом можно томкат спрятать за Apache HTTP Server, и поднимать по одному томкату на каждое приложение.
PZI>Ну все-таки это контейнер сервлетов, а не веб сервер. Поэтому его обязанности парсиньем запросов и отдачей ответов не ограничиваются.
Потому и не редеплоится нормально. Может, лучше "ограничить"?
M>>Уже пора его (веб сервер) оставить в покое. Ведь редеплоймент "на лету" — это то, чем занимается OSGi. А Томкат это умел всегда. И на простых приложениях это прекрасно работает.
PZI>Простые приложеня это парочка jsp? Так как если будет что-нибудь сложнее, то уже очень вероятно, что возникнут проблемы.
Конечно. В проблемах виновато приложение. Чем оно сложнее, тем больше в нем ошибок. А пары jsp достаточно, чтобы перебросить задание другому приложению и вернуть ответ на запрос. И тем самым "ограничить обязанности".
M>>А вев-приложения усложняются и теперь тут уже OSGi оказывается нужен. Но на серверной стороне есть же альтернатива в виде SOA, grid, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.
PZI>Зачем здесь OSGi? Зачем SOA для средненькой веб аппликухи? Усложнить аппликуху на пустом месте ради хот редеплоя? Зачем разбивать на куски то, что по сути является единым целым и при этом, кроме усложнения кода не получить никакой выгоды? О каких плагинах к томкату идет речь? Вы говорите о фреймворках как о плагинах, и хотя стоит признать, что в чем то они между собой похожи, но фреймворк != плагин.
Не ради только хот деплоя, но в том числе. Что такое "единое целое"? Парсить HTTP, общаться с базой через Hibernate и генерировать HTML? Наверное, удобно это считать одним целым и запихнуть в один war. Если не видно выгоды от разбиения приложения на более мелкие части, знает не надо этого делать.
Здравствуйте, mselez, Вы писали:
M>Здравствуйте, vb-develop, Вы писали:
VD>>С таким же успехом можно томкат спрятать за Apache HTTP Server, и поднимать по одному томкату на каждое приложение.
M>Тоже вариант
Здравствуйте, mselez, Вы писали:
M>Здравствуйте, PZI, Вы писали:
PZI>>Ну все-таки это контейнер сервлетов, а не веб сервер. Поэтому его обязанности парсиньем запросов и отдачей ответов не ограничиваются.
M>Потому и не редеплоится нормально. Может, лучше "ограничить"?
Ограничить ради чего? ради редеплоя? Какую смысловую нагрузку в данном случае будет нести томкат по Вашему?
M>>>Уже пора его (веб сервер) оставить в покое. Ведь редеплоймент "на лету" — это то, чем занимается OSGi. А Томкат это умел всегда. И на простых приложениях это прекрасно работает.
PZI>>Простые приложеня это парочка jsp? Так как если будет что-нибудь сложнее, то уже очень вероятно, что возникнут проблемы.
M>Конечно. В проблемах виновато приложение. Чем оно сложнее, тем больше в нем ошибок. А пары jsp достаточно, чтобы перебросить задание другому приложению и вернуть ответ на запрос. И тем самым "ограничить обязанности".
Какие ошибки то? Почему Вы решили, что проблемы с пермгеном возникают из за ошибок в приложении? То что вы предлагаете напоминает мне времена EJB2, тогда тоже было модно все разбивать на кусочки, хотя эти самые кусочки сами по себе никакого смысле не имели. И только ВСЕ эти кусочки собранные вместе, могли делать какую-то осмысленную работу. Кстате, это очень быстро умерло Почему так произошло я думаю легко можно нагуглить, заодно придет понимание, почему не надо на пустом месте разбивать аппликуху на кусочки.
M>>>А вев-приложения усложняются и теперь тут уже OSGi оказывается нужен. Но на серверной стороне есть же альтернатива в виде SOA, grid, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.
PZI>>Зачем здесь OSGi? Зачем SOA для средненькой веб аппликухи? Усложнить аппликуху на пустом месте ради хот редеплоя? Зачем разбивать на куски то, что по сути является единым целым и при этом, кроме усложнения кода не получить никакой выгоды? О каких плагинах к томкату идет речь? Вы говорите о фреймворках как о плагинах, и хотя стоит признать, что в чем то они между собой похожи, но фреймворк != плагин.
M>Не ради только хот деплоя, но в том числе. Что такое "единое целое"? Парсить HTTP, общаться с базой через Hibernate и генерировать HTML? Наверное, удобно это считать одним целым и запихнуть в один war. Если не видно выгоды от разбиения приложения на более мелкие части, знает не надо этого делать.
"Единое целое" это та бизнес задача которую должна решать аппликуха. Ну допустим разбили вы аппликуху на кусочки и добились прекрасного редеплоя по кусочкам без каких-либо проблем с пермгеном. Что дальше то? Какой бенефит получит бизнес от вашего редеплоя? Ну кроме того, что он получит более сложную архитектуру. Редеплой одного кусочка в любом случае аффектнет всю аппликуху.
Я ни в коем случает не против SOA и разбиения аппликухи, но считаю что делать это нужно тогда когда это действитльно нужно. И уж точно не ради редеплоя и не на такие мелкие части как предлагаете Вы.
У нас Томкат используется только для организации точек HTTP доступа в систему. Приложение — это окошко для курьера. Курьер (запрос) предьявил удостоверение, отдал посылку в окошко, получил другую посылку и унес. Приложение — index.jsp . Имя приложения (war'a) характеризует тип данных, которые им обслуживаются.
Да, наверное такой подход во многих случаях неприемлем.
.
Почему так произошло я думаю легко можно нагуглить, заодно придет понимание, почему не надо на пустом месте разбивать аппликуху на кусочки.