Смешались в кучу люди, кони.... IMHO

Решил по серверлетам 3.0 почитать, первая ссылка привела на хабр. Где говорят:
1. Появились аннотации
2. "Для поддержки длительных операций добавилась возможность асинхронной работы сервлета"
Откуда топик стартер взял измышления про NIO, мне в упор не ясно.

questionerquestionerГоворят, что у томката всего 200 потоков по умолчанию и он просто будет слать нафиг клиентов если у него нет более потоков.


Тут вот кстати непонтно, почему томкат не может либо расширить себе тред пул, либо ичпользовать тред пул с очередью, куда будут попадать задачи, которые приходят при заполненой очереди
Все бредовее и бредовее. И кто Вам такое говорит?

Про томкат не помню, а у апача и любых других вменяемых Web и апп серверов (Weblogic) - никаких 200 потоков нет. Их количество задается в файле конфигурации. И AFAIK значение по умолчанию около 10-и worker threads дабы обычно больше и не нужно и вредно )))

questionerвот тут про NIO
Что такое NIO знаю очень хорошо. Портировал _реальный_ проект на NIO (NIO через http://hc.apache.org/ с http://www.simpleframework.org/). Т.ч. все плюсы, минусы и глюки в относительно высоко нагруженной среде (сотни соединений, сервер 24x7 с 40 ядрами) на своей шкуре испытал )))

questionerСобственно в чем преимущество от сервлелов 3.0? когда их нужно использовать и когда не нужно?
Предполагаю тогда, когда нужны функции, которые появились в API 3.0.
Мне кажется, это очевидно.

Список фичь можно посмотреть например тут:
http://www.oracle.com/technetwork/server-storage/ts-5415-159162.pdf
Java™ Servlet 3.0 API: What's new and exciting

Список достаточно большой, что Вам из этого не понятно - я не знаю. При чем здесь NIO, так же не понимаю.

llemingпо умолчанию maxThreads=200, minSpareThreads=25
Ну то есть, как я и говорил, задается параметром.
Что не устраивает ТС, мне не понятно )))

Никогда tomcat в И-нет не открывал. Как в 90-ые приучили настраивать tomcat за apache http, так и настраиваю. Хоть и не знаю /не знал/ ))), чем это правильнее, чем чистый томкат.

Что в Apache HTTP, что в Weblogic кол-во worker threads явно исчисляется десятком или чуть больше. Т.к., по логике и административным документациям, кол-во одновременно работающих threads рекомендуют иметь максимум в 2-а раза большим, чем CPU. Т.ч. 200 одновременно выполняющихся тредов, это только для 100 процессорного сервера ))) или для устройства полного зависания системы в ситуации наподобие случайной DOS-атаки ))).

questionerЯ понимаю, что скорее всего это как-то не так работает ибо то, что я написал ничего не даёт.
Количество потоков будет даже больше, чем в изначальном варианте на 1(как минимум) поток.

Собственно в чем преимущество от сервлелов 3.0? когда их нужно использовать и когда не нужно?
Дает. Мы можем быстро освободить worker thread веб сервера.
Позволяет на захватывать системные (веб сервера) ресурсы, которые нам не принадлежат

Кроме того, не обязательно для каждого запроса порождать свой поток. Если несколько запросов может быть обработано одновременно, можно контекст запроса просто сохранить в какой ни будь коллекции и не плодить потоки. (получится или нет, зависит и от реализации Servlet API и разного шаманства)

В статьях используют сочетание "долго работающий запрос", на мой взгляд, это не совсем удачно. Т.к. долго выполняющийся запрос может быть по двум причинам:
1) он просто жрет CPU и что-то считает - тут ничего не поможет ))) кроме HP Super Dom'в )))
2) он не может обработать запрос, т.к. ждет каких-то внешних событий/ресурсов - а вот здесь, асинхронность может помочь очень сильно. IMHO & AFAIK

Сам с асинхронными сервлетами не работал. Но с NIO и обычными сервлетами работал.
IMHO & AFAIK

questionerКогда мы используем асинхронные потоки какой тредпул используется для потоков воркеров? кто его менеджит?

не знаю. Не использовал

questionerПускай у нас 200 потоков на томкате и 500 потоков в пуле по воркеров.
итого 700.
Будет ли разница с вариантом если просто в томкате выделить 700 потоков?
Так же не знаю. Думаю разница не сильно большая )))

Другое дело, что проблема не в потоках, а в программисте, который собирается делать такую похабень. Ну и совсем уж не ясно, зачем для такой похабени понадобились асинхронные фичи. Т.к. они и нужны IMHO , что бы кол-во потоков уменьшать (если это возможно)

Если же не получается, то проще томкат/http сконфигурировать на много-много потоков и не забивать себе голову. Я бы еще, архитектурно, поделил бы задачу на два http сервера. Один обычный, один для порнографии с потоками )))

Тут можно предложить два более жизненных сценария:

I

1. HTTP сервер с 10-ом или даже меньше worker threads который обрабатывает обычные/короткие http запросы
2.Длинные или "вялотекущие" HTTP запросы преобразуются в асинхронные и живут в отдельном помойке (путь даже Ваши 690 тредов). Для которых реализован свой велосипедный механизм управление.
Тогда асинхронные запросы, позволяют не портить очередь обработки нормальных запросов и реализовать велосипед для "специфических" случаев.

II,
Например реальная задача. Сервер слушает один источник данных (биржа), откуда приходят котировки (за бабло). У сервера есть свои клиенты-подписчики (несколько десятков/сотня открытых соединений, на самом деле каждое соединение это отдельная подсистема у которой тысячи реальных юзеров-брокеров).

В случае обычного IO, каждое соединение - поток, в котором редко-редко что ни будь происходит. Поток слушатель, при приходе новых котировок, помещает данные в очередь заинтересованных потоков-клиентов которые эти данные отсылают по сети. Потоков нужно много, сотни.. При этом потоки требуются только для поддержания IO.

В случае NIO:
Каждый подписчик, это просто ОБЪЕКТ s коллекции. Поток слушатель, при получение котировки, проходит по списку подписчиков и помещает данные в очередь клиента (если channel клиента в состояние suspend то он пробуждается), специальный поток ввода-вывода для всех активным channel'ов отсылает данные. Кол-во потоков исчисляется единицами.

Наверное аналогично можно организовать и через асинхронные сервлеты

Basil A. Sidorov]А вебсокеты - изврат, который получается у программистов, не читающих спецификацию. Это работающий изврат, но изврат.
Мне как-то кажется, что у вебсокетов вроде же свое API (в Tomcat'е), которое с subj связано совершенно опосредованно.

Могу ошибаться. Читал год назад, не освоил, в проекте не использовал (руки не дошли)

проблема не столько в web-socket'ах, сколько в попытках скрестить ежа с ужом в современных API

Даже по названию web-SOCKET и HTTP Servlets совершенно разные вещи, идеологически разные. Первое обмен данными по соединению, второе протокол вида запрос-ответ. В классическом, историческом виде. Ну а так, как генетиков сейчас много - все время попадается колючая проволока. Хотя даже и проволока, пусть и колючая, вещь полезная. Асинхронные сервлеты мне кажется из этой же оперы. Выглядит коряво, но поскольку других возможностей в сервел апи нет, спасибо и на этом. IMHO

А.П.Чехов. РевизорЧто там? веревочка? давай и веревочку! и веревочка в дороге пригодится: тележка обломается, или что другое, – подвязать можно

Basil A. SidorovЕдинственный сценарий, в котором необходимы асинхронные сервлеты - "конвейер".
Т.е. ситуация, когда вы принимаете данные клиента и можете выдавать ответ ещё до того, как будет прочитан весь входной поток.
Thanks. Возьму на заметку. Частая ситуация. Хотя с проблемами и не сталкивался.

Basil A. SidorovТолько, опять-таки, этот говнокод никак не связан асинхронностью. Если только тем, что для асинхронных сервлетов это совсем говнокод.

Если можно и не тяжело, киньте ссылку на нормальную доку как нужно

А то даже доки / примеры с oracle.com содержат говно код со своим пулом (((

Заранее благодарен.