в существующий проект на mvc, spring-webflux?
Работают ли асинхронные вызовы флакса в томкате ?
Я вот обнаружил что у меня запрос выполняется 14 сек, из-за синхронных запросов в сторонний сервис майкрософта. Тоесть 10 запросов выполняются 11+ сек. Хочу чтобы 10 запросов выполнялись за 2 сек. При этом чтобы не пришлось весь проект перерисывать на реактивный стек
Вообще непонятно, чем тебе поможет асинхронность тут.
Разом отправить 10 запросов например...
Отправь их разом синхронно из 10 разных потоков, радуйся жизни.
Это многопоток а не нон блокинг если разом
Переписывать микроскопический кусок приложения отдельно на асинхронный-реактивный стек, при этом оставляя всё остальное приложение без этого - вот это извращение. Многопоточность - не извращение.
Многопоток -> проблемы при скейлинге и кластеризации
Так а что это возможно разве? ты не будешь кусок сделать реактивным а все остальное нет же
был уже вопрос
Смотри, возвращай из контроллера CompletableFuture<T> заведи @Async конфиг и на нем выполняй свои запросы, они будут параллельными все фьючи композируй и отдавать контроллеру
Спасибо. Пошёл курить
Только если подключишь webflux будет одна маленькая проблемка, везде даже не в реактивных роутах добавляется content disposition
mvc это сервлеты, webflux с сервлетами нормально не дружит, это вкратце
в превьюшке вебфлакса был и томкат рядом с нетти, вот и думал что и томкат может
Он то может, только миксовать два апи нельзя
у webflux есть бэкэнд на Async Servlet
Это с какого перепугу?
Использование прямого многопотока вредно для масштабирования
Нельзя в томкате реактор, ему нетти нужен
Вообще ни разу, кто тебе это сказал?
да) было б конечно странно
Просто не нужно писать классы имеющие состояние. Почитай о функциональном программирование
Под многопотоком как таковым я там имел ввиду использование sync/wait/notify. тоесть многопоток на низком уровне
Ну можно же на более выском типо executor, completableFuture
Так а зачем ты его в виду-то имел? Тебе никто не предлагал все примитивы переписывать
Вообще мы использовали реактивный WebClient в mvc стеке. Вроде ничего страшного не произошло. Просто вызывали блокирующую операцию на Mono после всех параллельных вызовов.
А в чем был ризон юзать WebClient если под капотом синхронный томкат?
Когда нужно делать много параллельных rest вызовов, то профит что можно сделать много запросов не дожидаясь, когда придут ответы. И потом разом всего дождаться и агрегировать.
Так система же получит нагрузку с которой может не справиться , с большей вероятностью при таком раскладе?
Дак это и без вебклиента можно
Нет резона, только если он просто больше нравится ну и в доках спринга вроде его рекомендую, а рест темплейт типо устарел.
Не совсем так. Он переведен в режим maintenance only
Ключевое в том что на томкате нет резона юзать вебклиент за исключением рекомендации из доков или если он больше нравится
Ну про рест темплейт слышал , чет подзабыл , да и смотрю его не списывают со счетов пока осоьо
Не согласен. Как также легко можно организовать параллельность запросов? Самое близкое, что могу придумать - можно запараллелить стримы, но там это желательно делать на своем fork-join пуле, чтобы common pool не блочить IO операциями.
Completable future?
И там удобно потом смержить результат как раз
У веб клиента нет под капотом томката, это клиент, вызывающая сторона, а томкат это сервер Т.е. все ок, профит будет
Не понял, поток не залочиться? Т е будет асинк вызов на томкате? Что то не понимаю щас, ты же блочишь поток когда делаешь wait или что там у вебклиента
Приведите пример с completable future и давайте сравним его с WebClient
Ну я возможно не правильно понял. Уточню, вы делаете запрос вебклиентом и делает wait? Или блок что там у вебклиента
Я не про вебклиент, а про мвс уже было печатал что сказанул лишнего mvc != томкат , но вроде алттернативы там тоже не асинхронные
Да, но можно их наплодить и комбинировать
А чем это лучше completable future? Я помню делал две фьючи отправлял а потом как то мержил их же методами
Ничего не понял. А исходное сообщение про клиент
А чего вы в томкат-то все пинаете? Его заменить - одну зависимость добавить в проект
Я не пинаю, я пытаюсь понять преимущество вебклиента без реактивного стека в целом
Так это вообще не связано ведь)
Ну косвенно связанно, ибо поток томката то все ровно будет блокироваться, просто вот по ресурсам это менее затратно от future из сообщения выше) для меня это новая инфа)
У тебя внутри каждой фьючи залочится по потоку, а с вебклиентом пулинг всех запросов будет одним потоком
Да осознал благодарю
Я о томкате говорил что он в мвс , а не вебклиенте
Обсуждают сегодня