Re[12]: Tomcat и память
От: GarryIV  
Дата: 16.01.11 18:04
Оценка:
Здравствуйте, mselez, Вы писали:

GIV>>И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.


M>Даже если для реализации сервиса опять нужен Томкат, то перезапуск отдельного сервиса, как правило, не влияет сильно на всю систему.


Ровно в той же степени как и перезапуск Томката с веб приложением внутри.
WBR, Igor Evgrafov
Re[12]: Tomcat и память
От: PZI  
Дата: 16.01.11 20:10
Оценка:
Здравствуйте, mselez, Вы писали:

M>А почему для генерации HTML нужен Томкат? Эти UI фреймворки вне Томката не функционируют? Я просто не в курсе.


Вобще конечно можно запустить и без томката, вопрос только зачем?

M>На мой взгляд вся эта практика по встраиванию в веб сервер многочисленных фреймворков сомнительна.


Ну все-таки это контейнер сервлетов, а не веб сервер. Поэтому его обязанности парсиньем запросов и отдачей ответов не ограничиваются. Фреймворки встраиваются не в томкат, а в аппликуху.

M>Уже пора его (веб сервер) оставить в покое. Ведь редеплоймент "на лету" — это то, чем занимается OSGi. А Томкат это умел всегда. И на простых приложениях это прекрасно работает.


Простые приложеня это парочка jsp? Так как если будет что-нибудь сложнее, то уже очень вероятно, что возникнут проблемы. Но мы то не о hello word говорим, правильно?

M>А вев-приложения усложняются и теперь тут уже OSGi оказывается нужен. Но на серверной стороне есть же альтернатива в виде SOA, grid, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.


Зачем здесь OSGi? Зачем SOA для средненькой веб аппликухи? Усложнить аппликуху на пустом месте ради хот редеплоя? Зачем разбивать на куски то, что по сути является единым целым и при этом, кроме усложнения кода не получить никакой выгоды? О каких плагинах к томкату идет речь? Вы говорите о фреймворках как о плагинах, и хотя стоит признать, что в чем то они между собой похожи, но фреймворк != плагин.
Re[12]: Tomcat и память
От: vb-develop  
Дата: 17.01.11 08:52
Оценка:
Здравствуйте, mselez, Вы писали:

M>Здравствуйте, GarryIV, Вы писали:


GIV>>И кто в этой схеме будет генерацией HTML заниматься (где будет жить UI фреймворк)? Свой сервис? Тогда в него придется тоже контейнер пихать и рестартовать при изменении. Томкат? Здравствуй проблемы с редеплоем и необходимость рестарта контейнера.


M>Даже если для реализации сервиса опять нужен Томкат, то перезапуск отдельного сервиса, как правило, не влияет сильно на всю систему.


С таким же успехом можно томкат спрятать за Apache HTTP Server, и поднимать по одному томкату на каждое приложение.
Re[13]: Tomcat и память
От: mselez  
Дата: 18.01.11 01:58
Оценка:
Здравствуйте, vb-develop, Вы писали:

VD>С таким же успехом можно томкат спрятать за Apache HTTP Server, и поднимать по одному томкату на каждое приложение.


Тоже вариант
Re[13]: Tomcat и память
От: mselez  
Дата: 18.01.11 03:00
Оценка:
Здравствуйте, PZI, Вы писали:


PZI>Ну все-таки это контейнер сервлетов, а не веб сервер. Поэтому его обязанности парсиньем запросов и отдачей ответов не ограничиваются.


Потому и не редеплоится нормально. Может, лучше "ограничить"?

M>>Уже пора его (веб сервер) оставить в покое. Ведь редеплоймент "на лету" — это то, чем занимается OSGi. А Томкат это умел всегда. И на простых приложениях это прекрасно работает.


PZI>Простые приложеня это парочка jsp? Так как если будет что-нибудь сложнее, то уже очень вероятно, что возникнут проблемы.


Конечно. В проблемах виновато приложение. Чем оно сложнее, тем больше в нем ошибок. А пары jsp достаточно, чтобы перебросить задание другому приложению и вернуть ответ на запрос. И тем самым "ограничить обязанности".

M>>А вев-приложения усложняются и теперь тут уже OSGi оказывается нужен. Но на серверной стороне есть же альтернатива в виде SOA, grid, т.е. серверное приложение (в отличии от клиентского) может быть распределенным, состоять из набора мелких приложений(сервисов). А не развиваться как набор плагинов к Томкату.


PZI>Зачем здесь OSGi? Зачем SOA для средненькой веб аппликухи? Усложнить аппликуху на пустом месте ради хот редеплоя? Зачем разбивать на куски то, что по сути является единым целым и при этом, кроме усложнения кода не получить никакой выгоды? О каких плагинах к томкату идет речь? Вы говорите о фреймворках как о плагинах, и хотя стоит признать, что в чем то они между собой похожи, но фреймворк != плагин.


Не ради только хот деплоя, но в том числе. Что такое "единое целое"? Парсить HTTP, общаться с базой через Hibernate и генерировать HTML? Наверное, удобно это считать одним целым и запихнуть в один war. Если не видно выгоды от разбиения приложения на более мелкие части, знает не надо этого делать.
Re[14]: Tomcat и память
От: vb-develop  
Дата: 18.01.11 09:11
Оценка:
Здравствуйте, mselez, Вы писали:

M>Здравствуйте, vb-develop, Вы писали:


VD>>С таким же успехом можно томкат спрятать за Apache HTTP Server, и поднимать по одному томкату на каждое приложение.


M>Тоже вариант


Это то был стёб.
Re[14]: Tomcat и память
От: PZI  
Дата: 18.01.11 09:18
Оценка:
Здравствуйте, 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 и разбиения аппликухи, но считаю что делать это нужно тогда когда это действитльно нужно. И уж точно не ради редеплоя и не на такие мелкие части как предлагаете Вы.
Re[15]: Tomcat и память
От: mselez  
Дата: 18.01.11 14:20
Оценка:
Здравствуйте, PZI, Вы писали:

..

У нас Томкат используется только для организации точек HTTP доступа в систему. Приложение — это окошко для курьера. Курьер (запрос) предьявил удостоверение, отдал посылку в окошко, получил другую посылку и унес. Приложение — index.jsp . Имя приложения (war'a) характеризует тип данных, которые им обслуживаются.

Да, наверное такой подход во многих случаях неприемлем.

Большое спасибо за подробные комментарии.
Re: Tomcat и память
От: Blazkowicz Россия  
Дата: 19.01.11 10:15
Оценка:
Здравствуйте, Аноним, Вы писали:

Вот ещё по теме. Работы ведутся, чтобы облегчить девелоперам поиск утечек в пермген во время редеплоя.
http://www.tomcatexpert.com/blog/2010/04/06/tomcats-new-memory-leak-prevention-and-detection
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.