questionerНачал интересоваться play фреимворком.

Где-то зацепил мысль, что там внутри нет сервлетов.

А как тогда это может работать? Ну то есть есть html страница, есть java код. Как они ещё могут быть связаны как не через сервлеты?

Там либо это либо это


Alexey TominquestionerНачал интересоваться play фреимворком.

Где-то зацепил мысль, что там внутри нет сервлетов.

А как тогда это может работать? Ну то есть есть html страница, есть java код. Как они ещё могут быть связаны как не через сервлеты?

Не знаю play! ;) но Вы просто не понимаете сути.
Приложение слушает порт. Любое приложение может слушать любой порт.
При входящем зарпосе на этот порт вызывается некоторые метод.
Он должен вернуть ответ.
В случае html есть стандарт- что можно получить, что надо отдавать.

В java есть стандартная привязка этого к методам с помощью классов HttpServlet и GenericServlet.

Но это всё общий подход. Можно использовать что угодно. Более того, чтобы заработал Servlet надо чтобы сервер это обеспечил. См. например org.eclipse.jetty.server.HttpChannel.handle
+1

questioner,

Попробуй написать простой TCP сервер (используя java.net.ServerSocket) и добейся того, чтобы запросы обрабатывались параллельно а не по очереди. Многие вопросы тогда отпадут сами собой, в т/ч и про асинхронность.

Юрий321questionerпропущено...


Это для случая если мне из моего сервера надо сделать http запрос на другой сервер?

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

на пальцах если, оно работает так:

клиент запросил, сервер принял и считает, клиент ждет ответа, сервер отдает ответ, соединение закрывается - это обычное синхронное.

асинхронное работает так:
клиент запросил, сервер принял и ответил Ок (или Ошибка) и закрыл соединение, потом только начал считать.

далее может быть два варианта:

1) клиент периодически запрашивает сервер - как там моя задача, сервер отвечает или результатом счета, или кодом типа "пока считаю", "ошибка" и т.п.
Такое обычно называют polling.

2) клиент поднимает у себя свой собственный сервер (листен сокет), при запросе передает серверу свой адрес и слушает на нем ответ от сервера. Когда сервер заканчивает считать, он подключается к тому клиентскому "серверу" и отдает туда ответ.
Про такое говорят, что работает через callback.

Че правда что-ли?

Юрий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.