Андрей ПанфиловquestionerЕсли я ошибаюсь - хочу доказательства ибо такое не в одном месте встречал - например тут:
https://stackoverflow.com/a/18187372/2674303 Бгг, доказательств... вы сначала на пальцах попробуйте рассказать каким боком асинхронная обработка будет снимать нагрузку, в первом же приближении нам что "по классике", что "по новомодному" нужно один и тот же объем данных обработать и оснований полагать, что перенос обработки из одного места в другое что-то там может улучшить, нет никаких (есть малосущественный кейс с отдачей контента клиенту, но он решается более другими простыми способами).
Вот вы откуда-то выдумали:questionerЭто приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов.Ну освободили вы поток, что это дало-то? http-клиенту ничего не дало: он как ждал, так и будет продолжать ждать. Какой выигрыш вы получили для сервера? С большой долей вероятности вы наоборот потеряли: пока клиентские запросы висят в очереди они ничего не стоят, а как только вы их "частично обработали" и переложили в другую очередь то по крайней мере на памяти потеряли (плюс к этому контеншн с tcp-стека в лучшем случае на планировщик операционной системы переложили, а в худшем на базу). Думаете что у сервера приложений маленький пул? ну так увеличьте его, какая вам разница какой пул потоков увеличивать-то? Вот вам примеры из интернетов:
https://dzone.com/articles/spring-and-servlet-30-asynchronous-processing - мужик все правильно расписал
https://plumbr.io/blog/java/how-to-use-asynchronous-servlets-to-improve-performance - а вот это дичь, на которую вы ведетесь: подменили одно выполнение другим и говорим что стало лучше
нагрузку не снимается, сервер имеет возможность лучше обрабатывать пиковые нагрузки.
Я пока Ваши ссылки не читал, но сейчас почитаю.
Во первых контролировать тредпул на стороне приложения в любом случае удобнее. Мне не приходилось настраивать пул потоков в томкате, но могу предположить, что это несколько менее гибко, и скорее всего менее удобно. К тому же где гарантия, что все контейнеры это позволяют? Если в томкате 100 потоков и все они сейчас занимаются обработкой запроса, то 101 просто обломится, а не в очередь встанет. В случае с приложением мы можем настроить тредпул с очередью.
Ну вот ещё(автор если что ROSSEN STOYANCHEV):
https://spring.io/blog/2012/05/07/spring-mvc-3-2-preview-introducing-servlet-3-async-support In some cases you can return to the client immediately while a background job completes processing. For example sending an email, kicking off a database job, and others represent fire-and-forget scenarios that can be handled with Spring's @Async support or by posting an event to a Spring Integration channel and then returning a confirmation id the client can use to query for the results.
In other cases, where the result is required, we need to decouple processing from the Servlet container thread or else we'll exhaust its thread pool. Servlet 3 provides just such support where a Servlet (or a Spring MVC controller) can indicate the response should be left open after the Servlet container thread is exited.
To achieve this, a Servlet 3 web application can call request.startAsync() and use the returned AsyncContext to continue to write to the response from some other separate thread. At the same time from a client's perspective the request still looks like any other HTTP request-response interaction. It just takes longer to complete. The following is the sequence of events:
Client sends a request
Servlet container allocates a thread and invokes a servlet in it
The servlet calls request.startAsync(), saves the AsyncContext, and returns
The container thread is exited all the way but the response remains open
Some other thread uses the saved AsyncContext to complete the response
Client receives the response
https://spring.io/blog/2012/05/07/spring-mvc-3-2-preview-introducing-servlet-3-async-support
