Юрий321dimonz80,

ну я вобщем не про скалу, а про клиент-сервер поверх http

а что, в скале выдумали свой свой собственный хттп и там теперь по другому?

У ТС вопрос был про асинхронность в Play Framework, т.е. с серверной стороны. А вы начали про клиентские штуки, которые немного не то.

Юрий321dimonz80,

ну я вобщем не про скалу, а про клиент-сервер поверх http


Не нравится скала, вот про java)))

dimonz80Юрий321dimonz80,

ну я вобщем не про скалу, а про клиент-сервер поверх http


Не нравится скала, вот про java)))


Упс! Поторопился )))
Не нравится скала, вот про java)))

questionerBlazkowiczquestioner,

Разговор опять сводится к "мне не понятно". Давай конкретные вопросы.

Есть клиент, есть сервер. Клиент шлёт запрос на сервер, сервер в новом потоке начинает обработку запроса. Зачем делать в это в новом потоке мне непонятно потому что все равно надо будет ждать когда задача в новом потоке закончится. Или асинхронность в другом чем то?


Попробую рассказать...

Самый простой случай

Тривиальный сервер
0) Запускаем основной процесс/поток (main)
1) main cлушает порт
2) При соединении клиента работает с клиентом (читает и пишет в сокет)
3) Goto п.1

Такой сервер может обслуживать только одного клиента за раз. Остальные - в очередь.



Классический сервер
0) Запускает основной процесс/поток (main)
1) main cлушает порт
2) При соединении клиента форкает себя (как httpd или postgresql например) или создает thread (или берет из пула).
3) В новом созданном процессе/потоке работает с клиентом (читает и пишет в сокет)
4) параллельно п.3 основной поток (main) продолжает слушать порт пока не случится п.2 (goto п.1)

Такой сервер обслуживает пачку клиентов одновременно. Он по большому счету уже асинхронный.


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

Такой сервер работает приверно так:
0) Запускает основной процесс/поток (main)
1) main cлушает порт
2) При соединении клиента берет thread из пула
3) В полученном потоке вычитывает данные из сокета и передает из другому потоку (опционально полученному из другого пула), который будет тупить, ждать IO и в отдаленном будущем ответит клиенту. Сам же поток из п.2 сразу возвращается в пул для обслуживания других запросов
4) параллельно п.3 основной поток (main) продолжает слушать порт пока не случится п.2 (goto п.1)

questionerdimonz80Самый простой случай

Тривиальный сервер
0) Запускаем основной процесс/поток (main)
1) main cлушает порт
2) При соединении клиента работает с клиентом (читает и пишет в сокет)
3) Goto п.1

Такой сервер может обслуживать только одного клиента за раз. Остальные - в очередь.



А как будет поддерживаться очередь?


ОС

questionerdimonz80 Классический сервер
0) Запускает основной процесс/поток (main)
1) main cлушает порт
2) При соединении клиента форкает себя (как httpd или postgresql например) или создает thread (или берет из пула).
3) В новом созданном процессе/потоке работает с клиентом (читает и пишет в сокет)
4) параллельно п.3 основной поток (main) продолжает слушать порт пока не случится п.2 (goto п.1)

Такой сервер обслуживает пачку клиентов одновременно. Он по большому счету уже асинхронный.


В моём представлении всякие джетти/томкаты так и работают.

Тогда непонятно, что непонятно))))
Так работают все TCP серверы. Пресловутая асинхронность добавляет лишь еще одни уровень распараллеливания,
чтобы быстрее высвобождать потоки, непосредственно обслуживающие соединения.

questionerdimonz80пропущено...


Тогда непонятно, что непонятно))))
Так работают все TCP серверы. Пресловутая асинхронность добавляет лишь еще одни уровень распараллеливания,
чтобы быстрее высвобождать потоки, непосредственно обслуживающие соединения.

А play приложение крутится на чем? оно ведь тоже во что-то пакуется наверное и куда-то деплоится.

А как обычные сервлеты мешают этому дополнительному слою асинхронности?

Или что-то из коробки добавляется?


Play по дефолту никуда не пакуется. Play сам себе сервер. Там выше были ссылки с указанием, что используется под капотом (Netty или akka.http). При желании можно собрать war (есть плагин) для деплоя в сервлет-контейнере.

Сервлеты с версии 3 вроде как умеют в асинхронность.

Все эти серверы (как сервлет контейнеры так и и остальные) принципиально ничем не отличаются. Сначала пишем обработчик для запроса в виде колбека, сервлета, хендлера или как его там назовут авторы очередного фреймворка, мапим его на URL и все! Сервлет-контейнеры выделяются среди всего этого лишь наличием спецификации от Sun/Oracle.