Асинхронный JAX-RS

Question

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

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

Что я не понял, так это то, что клиент все еще ожидает ответа, и, следовательно, между клиентом и сервером все еще поддерживается активное соединение. Разве это не поддерживается в потоке ввода / вывода? Что значит приостановленный здесь?

Кроме того, даже если дело в том, что поток ввода-вывода освобожден из-за делегирования процесса рабочему соединению с клиентом, все еще работает, как сервер может принимать все больше и больше соединений тогда?

И мой следующий вопрос о пуле потоков, используемом здесь. Потоки ввода-вывода и рабочие потоки из разных пулов? потоки рабочих / процессоров не приходят из пула, управляемого сервером?

Из-за того, что я не понял этого, я подумал о том, чтобы просто иметь отдельный пул для ввода-вывода, а обработка с подключенным клиентом все равно, что блокировка ввода-вывода с обработкой внутри справа

Я не очень хорошо понял эту концепцию.

Answer 1

Пулы потоков, используемые в этом сценарии:

1. пул обработки запросов, управляемый контейнером JAX-RS (например, Джерси), и
2. Пул рабочих потоков, обычно управляемый вашим собственным кодом.

Возможно, с соединением связан поток ввода-вывода, но это детали реализации, которые на это не влияют.

Когда вы используете AsyncResponse, как только вы возвращаетесь из своего метода handle, поток обработки запросов (из пула # 1) освобождается и может использоваться контейнером для обработки другого запроса.

На ваши вопросы:

1. "... как сервер может принимать все больше и больше соединений?" - он может принимать больше соединений, чем если вы не используете AsyncResponse для длительных запросов, потому что вы освобождаете один из ваших ограниченных ресурсов (потоков в пуле потоков # 1). Само соединение не освобождается, и соединения также являются ограниченными ресурсами, так что вы можете исчерпать их (а также, возможно, быть ограничены ЦП или памятью).
2. "рабочие потоки / процессоры не приходят из пула, управляемого сервером?" - не нормально. Смотрите пример в ссылке от Paul Samsotha здесь - код приложения сам создает новый поток. Вероятно, это не то, как вы бы это делали, вы, скорее всего, захотите использовать ExecutorService или подобное, но дело в том, что вы сами управляете «рабочим потоком». Исключением здесь является использование аннотации @ManagedAsync на Джерси.
3. На ваш последний вопрос должен ответить мой ответ # 1 - на более низком уровне все еще есть ресурс, связанный с соединением, даже если вы используете AsyncResponse, но AsyncResponse освобождает обработку запроса контейнера потоков, количество которых может быть более ограничено, чем максимальное количество соединений. Вы можете решить эту проблему, изменив конфигурацию сервера вместо использования AsyncResponse, но AsyncResponse имеет два преимущества: оно находится под контролем приложения и для каждого запроса, а не для сервера.