Ну т.е. если ты имел ввиду потоки на ядрах, то конечно тут уже тяжелая арифметика - никогда до конца не понятно, насколько удачно сложатся команды на выполнение. А если ядра - то у T2 их до 8, и каждый из них 1.2-1.4.

тёплое с мягким путать не надо :)

Заменят и еще как...

В прошлом году при использовании tomcat версии 6.0.X иногда терялось содержимое POST-запросов. Причем по случайному закону. Клиенты были очень недовольны. Баг был заведен, проблема до сих пор неразрешена. Когда я заглянул в код Tomcat, то слегка был шокирован его качеством и отсутствием нормальной javadoc. Потеря тела запроса происходила в классе HttpProcessor.java... (https://issues.apache.org/bugzilla/show_bug.cgi?id=47797)

Начиная с того момента я не верю в то что говорят, а проверяю качество исходного кода самостоятельно. Пришлось перейти на Jetty. Там качество кода получше. И читаемость на уровне. И что самое главное, потери тел POST-запросов прекратились :).

Всем желаю удачного программирования и правильного|осознанного выбора контейнера.

Пришлось перейти на Jetty. Там качество кода получше. И читаемость на уровне.

Как там с UTF-8?

никаких проблем не было.

Спасибо!

Не трололо ради, а общего образования для:

Как решаете проблему с утечкой пермгена при рестарте отдельных варок в контейнере? Например, активная разработка сервиса и, как следствие, частый редеплой, ведущий к OutOfPermgen после пяти-десяти итераций.

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

OutOfPermgen - это проблема в основном связанная, с переполнением памяти для классов.
--------
Какая JVM ?
------------------------------------
Если HotSpot то необходимо включить PermGenSpace:
-XX:PermSize=512m
+ включить сборщик мусора в области PermGenSpace:
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
------------------------------
Мы используем JRockIt. Там поступили умнее: память для классов выделяют непосредственно в системной памяти. Так что просто следите за потреблением общей памяти.
-------------------------------
В OpenJDK не в курсе. Не пользовал.
-------------------------------

И еще кое-что. Если используется javaassist (например в Hibernate) то он при высоком конкуррентном доступе может вызывать утечку памяти в PermGen (HotSpot) либо системной (JRockIt). Он просто генерит кучу разных прокси классов для одного исходного класса если запросы приходят из разных потоков выполнения. Баг до сих пор не разрешен. Будьте внимательны!.

А Jetty|Tomcat тут не причем :). Это все JVM.

OutOfPermgen - это проблема в основном связанная, с переполнением памяти для классов.

Да, возникающая из-за невозможности собрать ClassLoader приложения при его останове, так как на эти классы есть ссылки из других ClassLoader'ов (например контейнерного).

Какая JVM ?

HotSpot

Если HotSpot то необходимо включить PermGenSpace: -XX:PermSize=512m

Ну это только отсрочит гибель контейнера.

включить сборщик мусора в области PermGenSpace: -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Nope, не помогает. Так как ссылки все равно остаются, поэтому классы и не собираются.

Мы используем JRockIt. Там поступили умнее: память для классов выделяют непосредственно в системной памяти. Так что просто следите за потреблением общей памяти.

Тоже хотели переходить на него, но я где-то прочитал, что там тупо гигабайтный пермген по-умолчанию, то есть полностью проблему опять не решает.

А Jetty|Tomcat тут не причем

Это понятно, что контейнеры не при делах, просто jetty, обычно, используется как запускалка для одной варки с последующим рестартом всей jvm при редеплое, поэтому такой проблемы там и нет. Томкат хотелось бы поставить на интеграционный тестсервер, так как процесс деплоя достаточно легок. Но частый редеплой тестируемых сервисов мешает этому.

Если на класс кто-нибудь ссылается, то сборщик не удалит его как ни крути. В JRockIt PermGen может расти до размеров: 32bit:~ 4GB - HEAP Size - ThreadsSize. Текущее состояние можно определить командой:

jrcmd PID print_memusage.

пример: Total mapped 2443164KB (reserved=5184KB) - Java heap 2097152KB (reserved=0KB) - GC tables 70156KB - Thread stacks 25244KB (#threads=180) - Compiled code 12672KB (used=11985KB) - Internal 648KB - OS 72328KB - Other 83812KB - Java class data 80128KB (malloced=79958KB #105620 in 18634 classes) - Native memory tracking 1024KB (malloced=157KB #8)

Нас интересует строка Java class data. Здесь так же видно куда уходит память помимо кучи. За class data надо следить на production. Если растет, то это потенциальный баг.

Ok. Более внимательно присмотрюсь к JRockit. Спасибо за консультацию.

гм, lor без такого фильтра успешно работает

Удачненько :) Как раз под новый проект :)