Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
 Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1716
Суть использования асинхронных сервлетов в том, что мы можем вернуть DefferedResult(Если работать через spring). Это приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов. Далее контроллер вызывает сервис, базу в отдельном треде и как только у нас есть ответ, то мы говорим, что досчитали defferedResult и работа передаётся в тред томката.

Есть какой-то новый reactive spring webflux

https://stackoverflow.com/questions/46606246/spring-mvc-async-vs-spring-webflux/46621923

Я что-то не могу понять в чём принципиальное отличие.
27 июн 19, 16:59    [21916432]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 618
questioner,
Зачем дубль темы?
27 июн 19, 17:12    [21916452]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1716
servlet 3.1 вполне себе использует NIO https://stackoverflow.com/questions/39802643/java-async-in-servlet-3-0-vs-nio-in-servlet-3-1
27 июн 19, 17:22    [21916457]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1716
Tomcat 8.5+ поддерживает это всё.

https://dzone.com/articles/servlet-31spring-mvc-non-blocking-io

Зачем тогда webflux?
27 июн 19, 17:25    [21916462]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 618
questioner
Зачем тогда webflux?
а зачем ты подымаешь всё Г. которое на земле валяется?
Это хайповое реактивное программирование.
Совсем другое по сути.
27 июн 19, 17:30    [21916466]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
redwhite90
Member

Откуда:
Сообщений: 1901
PetroNotC Sharp
questioner
Зачем тогда webflux?
а зачем ты подымаешь всё Г. которое на земле валяется?
Это хайповое реактивное программирование.
Совсем другое по сути.


Ты тут чтоб на вентилятор накинуть? Нечего ответить - помолчи.


Weblflux построен на servlet 3.1 для томката, так что никакой магии нет. Еще есть Фишечка, что эта либа умеет в рантайме размеры внутренних пулов тюнить
27 июн 19, 18:36    [21916520]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 618
redwhite90
Нечего ответить - помолчи.
жду твое молчание на
Flux<T>
27 июн 19, 18:53    [21916538]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
redwhite90
Member

Откуда:
Сообщений: 1901
PetroNotC Sharp
redwhite90
Нечего ответить - помолчи.
жду твое молчание на
Flux<T>


Что?
27 июн 19, 19:08    [21916558]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3249
questioner
Суть использования асинхронных сервлетов в том, что мы можем вернуть DefferedResult(Если работать через spring). Это приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов. Далее контроллер вызывает сервис, базу в отдельном треде и как только у нас есть ответ, то мы говорим, что досчитали defferedResult и работа передаётся в тред томката.
В что что вы описали нет никакого смысла, какая разница между тем, что запрос обрабатывается в http-потоке или в каком-то другом? Разницы нет никакой, а профит появляется только тогда, когда мы умеем обрабатывать отложенные запросы пачками.
27 июн 19, 19:19    [21916572]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 618
redwhite90
PetroNotC Sharp
пропущено...
жду твое молчание на
Flux<T>


Что?
нечего по теме сказать - молчи.
27 июн 19, 19:44    [21916585]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1716
Андрей Панфилов
questioner
Суть использования асинхронных сервлетов в том, что мы можем вернуть DefferedResult(Если работать через spring). Это приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов. Далее контроллер вызывает сервис, базу в отдельном треде и как только у нас есть ответ, то мы говорим, что досчитали defferedResult и работа передаётся в тред томката.
В что что вы описали нет никакого смысла, какая разница между тем, что запрос обрабатывается в http-потоке или в каком-то другом? Разницы нет никакой, а профит появляется только тогда, когда мы умеем обрабатывать отложенные запросы пачками.


Это фича сервлет 3.0. Как я понимаю суть в том, чтобы сервер мог хотя бы принимать запросы даже если он не справляется с нагрузкой, чтобы все потоки контейнера не были заняты.
Например в томкате 100 потоков по дефолту и скажем запрос занимает 5 секунд. И к нам прилетает 101-ый запрос В случае 2.5 мы не можем принять запрос вообще, а в случае 3.0 мы спокойно примем запрос и передадим в другой пул с очередью. Если я ошибаюсь - хочу доказательства ибо такое не в одном месте встречал - например тут: https://stackoverflow.com/a/18187372/2674303
27 июн 19, 23:48    [21916669]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1716
Андрей Панфилов, https://stackoverflow.com/a/3810625/2674303

Вот вообще похожая формулировка вопроса
28 июн 19, 00:02    [21916673]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3249
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 - а вот это дичь, на которую вы ведетесь: подменили одно выполнение другим и говорим что стало лучше
  • 28 июн 19, 01:23    [21916679]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 618
    Андрей Панфилов,
    +1

    questioner
    Это фича сервлет 3.0. Как я понимаю суть в том,

    Все время суть от вас ускользает.
    Вы писали хоть одно асинхронное на сервлетах?
    То которое, крнтейнер не смог, а вы своим кодом смогли?
    Теория без практики мертва.
    Опять рассуждаете о DI не написав ни строчки кода в топике.
    28 июн 19, 09:23    [21916741]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 618
    Андрей Панфилов
    Ну освободили вы поток, что это дало-то?

    OFF/2
    В шарпе MS такая парадигма. Потому что у них нет контейнера с потоками и прогеры сами пишут Async через строчку.
    Типо помогают серверу.
    Но думаю что скоро перейдут к решению из java. Уж очень муторный код в итоге на бэке.
    Имхо
    28 июн 19, 09:37    [21916752]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1716
    PetroNotC Sharp
    Андрей Панфилов,
    +1

    questioner
    Это фича сервлет 3.0. Как я понимаю суть в том,

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


    Уважаемый(нет), уймись уже. от тебя толку ноль.
    28 июн 19, 11:17    [21916864]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 618
    questioner,
    Почему то каждый, кто пилит код лет 5, или около того считает что может разговаривать про архитектуру.
    Увы. Это другая область знаний.
    ДРУГАЯ.
    Поэтому, мембер, мне не надо отвечать. Разговаривай по теме топика.
    28 июн 19, 11:31    [21916874]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1716
    Андрей Панфилов
    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
    28 июн 19, 11:33    [21916879]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1716
    Про очередь конкретно у томката я прогнал, признаю - https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html
    28 июн 19, 11:56    [21916902]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3249
    questioner
    нагрузку не снимается, сервер имеет возможность лучше обрабатывать пиковые нагрузки.
    Физика под этим "лучше обрабатывать" какая лежит? Вот мы берем "типичное" приложение и затаскиваем весь говнокод из контроллеров в DefferedResult - в каком месте и из-за чего оно начнет что-то "лучше обрабатывать"? или таки есть специфичные кейсы где мы можем получить неиллюзорный профит а в остальных случаях ничего кроме геморроя не получить? Вы вообще задумывались по какой причине топят за всякие фиберы в жаве и реактивное программирование? почему поток - это плохо?
    28 июн 19, 12:22    [21916929]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    сладкий бубалех
    Member

    Откуда:
    Сообщений: 31
    Андрей Панфилов
    questioner
    Суть использования асинхронных сервлетов в том, что мы можем вернуть DefferedResult(Если работать через spring). Это приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов. Далее контроллер вызывает сервис, базу в отдельном треде и как только у нас есть ответ, то мы говорим, что досчитали defferedResult и работа передаётся в тред томката.
    В что что вы описали нет никакого смысла, какая разница между тем, что запрос обрабатывается в http-потоке или в каком-то другом? Разницы нет никакой, а профит появляется только тогда, когда мы умеем обрабатывать отложенные запросы пачками.


    почему нет смысла? а как на счет того, что поток это жирно для ОС(процесс для ОС еще жирнее, к примеру) и мы можем переложить выполнение некоторых задач(чтение-запись файла) на потоки ядра, которые еще сильнее оптимизированы и тоньше.
    nginx работающий по такому принципу, значительно производительнее apache, который создает потоки для каждого подключения
    28 июн 19, 12:33    [21916943]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 618
    questioner
    Ну вот ещё(автор если что ROSSEN STOYANCHEV):

    вы у автора уточните.
    Он беспокоится за оптимизацию бэка или клиента?
    У клиента при асинхронном программировании методом AJAX и так всё шеколадно.
    Он ждёт Асинхронно ответ (в разумных пределах таймаута) и его ничего не парит.
    Ему не нужно сразу возвращать управление(ответ).
    Поэтому забудьте о клиенте при доказательствах нужности.
    28 июн 19, 12:37    [21916946]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1716
    PetroNotC Sharp
    questioner
    Ну вот ещё(автор если что ROSSEN STOYANCHEV):

    вы у автора уточните.
    Он беспокоится за оптимизацию бэка или клиента?
    У клиента при асинхронном программировании методом AJAX и так всё шеколадно.
    Он ждёт Асинхронно ответ (в разумных пределах таймаута) и его ничего не парит.
    Ему не нужно сразу возвращать управление(ответ).
    Поэтому забудьте о клиенте при доказательствах нужности.


    Вот неуёмный какой)) не угомониться ему никак.
    28 июн 19, 12:40    [21916949]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 618
    сладкий бубалех
    что поток это жирно для ОС

    Контейнер создавали чтобы в прикладном коде программист меньше думал о потоках.
    Иначе нужны цифры и доказательства. Накладные расходы растут.
    28 июн 19, 12:40    [21916950]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 618
    questioner
    Вот неуёмный какой)) не угомониться ему никак.

    по теме, по теме пишите.
    А то вы сначала отвечаете, а потом ссылки читаете)).
    28 июн 19, 12:41    [21916952]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
    Все форумы / Java Ответить