just_vladimir,

Всё сильно зависит от требований.
HttpURLConnection
+ Нет надобности тащить дополнительных либ. Для коробочного продукта это важно. Для сервера - не шибко.
- Сильная трудоёмкость составления не примитивных HTTP запросов. POST, мультиформ и т.п.
- Обычный блокирующий IO

В чем принципиальная разница между Apache и Ning я не знаю. И гугл тоже не шибко чего толкового пишет на этот счет. Вроде оба должны через NIO работать.

Во всех трех вариантах для сервера надо смотреть как либа работает с потоками. Если не использовать JEE API для асинхронных задач, то можно выхватить PermGen/MetaSpace leak на ExecutorServices, даже если использовать shutdown().

Leonid KudryavtsevМожно подробнее с этого места?
http://rsdn.ru/forum/java/5974292.1
Мы по-моему уже с тобой спорили на этот счет.
Когда внутри JEE модуля создаётся новый поток, то у него ThreadContextClassloader ссылается на ClassLoader JEE модуля. Через какие ещё сопли это утекает дальше я не разбирался. Но утекает.
Вот тут чуть более детально:
http://stackoverflow.com/a/6540248

Это одна из причин почему JEE спека требует не создавать новых потоков, а использовать API контейнера или JEE чтобы потоки создавал сам контейнер.

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

just_vladimirПо сабжевой теме еще вопросик, для случая, если запросы синхронные (от пользователя с клиента пришел http запрос, в процессе его обработки помимо всего прочего нужно сходить с http запросом еще на другой бэкэнд и уже по итогу сформировать ответ пользователю), то никакого профита от неблокирующего IO я ведь не получу?
Ну, да. Никакого профита особого не будет. Не знаю, что там в HTTP, но в NIO Socket API можно блокировку просто флагом регулировать. В результате, один и тот же код можно использовать в разных сценариях, как синхронных так и асинхронных. Но это всё больше "в теории".

Leonid KudryavtsevВряд ли спорили )))

Угу. Не с тобой:
18216361

Leonid KudryavtsevТ.к. эту багу знаю, но это больше не Subj, а достаточно известные баги Tomcat'а.
Возможно. Буду благодарен за ссылку. Но это никак не отменяет того факта что JEE спека настоятельно не рекомендует порождать потоки.

just_vladimirА какие еще потенциальные проблемы могут возникать, из-за того, что я, например, руками создаю потоки? Ну кроме вышеописанного и того, что мой EE сервер чувствует себя неполноценным от того, что я что то делаю, что не находится у него под чутким контролем.
А то я по наивняку создавал и запускал треды и вроде бы все было более менее хорошо.
Ну, на сколько я понимаю, ты просто в новых потоках должен быть аккуратнее при использовании JEE API. Контейнер может в ThreadLocal держать любой контекст, и в потоках, которые ты создаешь, этот контекст, понятное дело, не виден. Но так как у нас pure JEE приложения почти никто не пишет, то эта проблема и не актуальна.

rema174один чел говорит чтобы создать leak: start a thread in a servlet container and don't return from it's run method
непонятно...

Живой поток это GC Root. Это вообще leak, а не PermGen leak.

rema174если так, то в веб-приложении такой пример это leak..? ерунда какая-то...


У тебя тут есть возврат из run(). Добавь while(true) и будет утечка.
Но! Как тут пишут, только в Tomcat, new Thread().start() приводит к утечке в PermGen. Это другая утечка вообще.

Leonid KudryavtsevBlazkowicz, давайте поподробнее. Утечка PermGen на Thread.start или при ре-деплои приложения?
Утечка PermGen на Thread.start(). При чем тут редеплой вообще? Редеплой просто создаёт ещё один ClassLoader, а старый никуда не дивается, потому что ссылка на него засела где-то во внутренностях Java.

Leonid Kudryavtsev1) Первое - критично, т.к. будет утечка на работающем сервере.

Я вообще не врубаюсь о чем ты. Речь про ссылки, которые не дают GC собрать WebAppClassloader. В этом и есть суть утечки в PermGen.

Leonid Kudryavtsev2) Второе - значительно менее критично, просто значит, что при редиплое приложения нужно обязательно перегружать томкат. Неприятно, но если об этом помнить, не смертельно. Утечка при редиплое видел и без всяких Thread в своем коде (был ли Thread в коде библиотек - не очень понятно).
Не смертельно, но не приятно. У меня нет никакого желания перезагружать публичный сервис. 24x7 вполне себе объяснимое желание. При этом апдейты я переодически накатываю по несколько раз на день. Когда у тебя внутрикорпоративная система и ночью все пользователи спят - это одно. А когда у тебя публичный сервис и ты понятия не имеешь когда все перестанут его использовать, это другое.

rema174не вполне понятно про что речь - допустим нужно запустить тред из сервлета, который закончится после того, как респонс будет отправлен. как тогда его запускать?

Куча способов:
http://docs.oracle.com/javaee/1.4/api/javax/resource/spi/work/WorkManager.html
https://docs.oracle.com/javaee/7/tutorial/servlets012.htm
http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
http://docs.oracle.com/javaee/6/tutorial/doc/bncdq.html

Leonid KudryavtsevПри том, что Thread.start к PermGen вообще ни каким боком ==> т.ч. там утечки быть не может. А resouce leak (в том числе и на классы/class loader) можно сделать где угодно.
Мля, да что же за херню вы тут пишете? Сколько раз можно объяснять-то? Thread.start() регистрирует ссылку на свой ContextClassLoader в недрах Java за пределами веб-приложения. Это и приводит к невозможности удалить ClassLoader и все загруженные им классы из кучи. Что и является утечкой в PermGen, в котором все эти классы и живут.

Leonid KudryavtsevУтечки происходит при редиплое, т.к. resource leak в прикладном коде не позволяет корректно (as expected админом-пользователем) отработать редиплою.
Редеплой это то на что утечка влияет. И то что приводит к росту потребления памяти. Сама же по себе утечка происходит при Thread.start().

Leonid KudryavtsevИ про проблемы с ClassLoader'ом пишут только для Tomcat. Другие сервера, как-то умудряются более корректно "прибить" и "кильнуть" залипшие приложения.
Ссылку на багу в Tomcat связанную с Thread.start(), я тут пока не увидел. Так что мало ли кто где чего пишет. Все контейнеры изолирующие модули через иерархию ClassLoader-ов имеют этот косяк.

Leonid KudryavtsevВообще, в этом плане, Java и Java application server'а вещь достаточно бредовая и глючная. Т.к. heap совместно используется всеми приложениями (в данном случае разными версиями одного приложения) и resource leak сказывается на всех. Т.ч. с безопасностью и изолированностью проблемы офигенные.
Правильно. Поэтому standalone сервера и микро-сервисы теперь в тренде.

Leonid KudryavtsevИ про проблемы с ClassLoader'ом пишут только для Tomcat.
Вот тебе про WebSphere тоже самое
http://wasdynacache.blogspot.com/2012/01/websphere-classloader-memory-leak.html
Там, кстати, интересный совет исправить проблему через doPrivileged()

Valery ShiskinЧестно говоря я не понимаю, какие у java или JEE7 App серверов, такие уж офигенные проблемы. Потоки можно создавать, используя ManagedExecutorService. А что касается безопасности, то причем здесь Java? С этим не все в порядке даже в ЦРУ и АНБ.
Ай, спасибо. Так как JEE не исповедую, то совсем забыл что там ввели соответствующий пакет.
http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/package-summary.html

Valery ShiskinНо ведь Spring исповедуете.

Spring не JEE.

Valery ShiskinИ сервлеты тоже.
Уже нет. Попробовал 3.0 - ну их нафиг.

Valery ShiskinИли Web (или WAR) Profile не относится к JEE ?
Когда приложение сам себе контейнер, то это уже далеко от JEE.