Как Play Framework отслеживает заблокированный клиент и возвращает ответ - PullRequest
Новая
       13

Как Play Framework отслеживает заблокированный клиент и возвращает ответ

0 голосов
/ 07 сентября 2018

Вопрос касается конкретно Play Framework, хотя концепция является общей. Я предполагаю, что заблокированный клиент прослушивает сокет, который отслеживается на стороне сервера и передается с Future [Result], так что, когда Future заканчивается, тогда ответ записывается в сокет, а затем сокет закрывается.

Может кто-нибудь поделиться более конкретным объяснением со ссылками?

Цитирование из:

https://www.playframework.com/documentation/2.6.18/ScalaAsync

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

1 Ответ

0 голосов
/ 10 сентября 2018

  1. Обратите внимание, что Play не управляет обращением к клиенту. Это управляется TCP . По сути (в качестве простой аналогии) вы можете думать о клиенте, как о веб-браузере, как о телефонном звонке на сервер. Когда клиент делает запрос, один из его сокетов подключается к определенному сокету на сервере - это постоянное соединение между сокетами на время запроса / ответа. Базовый сервер Play (Netty для более старых версий или Akka Http для v2.6 +) примет входящий запрос от сокета и назначит ему поток. Play выполнит эту работу, и полученный ответ будет возвращен сервером на правильный сокет. TCP-сервер будет управлять отображением между ответом и сокетом, а не Play.

  2. Как уже отмечали другие, ссылка на блокирование в основном связана с тем, как должны действовать игровые действия (неблокирование). Они принимают запрос, оборачивают любую работу, которую вы закодировали в Future, и передают ее, чтобы завершить в какой-то момент в ближайшем будущем (это может быть другой поток, который завершает Будущее, или он может даже оказаться та же нить). Дело в том, что создание Future происходит быстро, и поэтому поток, обработавший запрос, быстро возвращается в пул, чтобы он мог получить другой запрос для работы. Если вы слышали о Реактивном Программировании , то это, по сути, идея сохранения Отзывчивости Приложения.

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

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

Это немного больше, но, надеюсь, это даст немного больше контекста этому конкретному утверждению из документации Play.

...