Не совсем поняла вопрос, в чем смысл использовать thread per request, если используешь nio(epoll, в частности). Кажется, весь смысл асинхронных серверов чтоб не плодить дорогие потоки.
Если заблочить поток томката ещё не страшно, а если заблочить поток нетти будет очень плохо
Ну это понятно, так как он создает поток на запрос, но где тогда асинхронность?
Не создаёт. Потоки берутся из пула
Ну так это не то. То, что потоки берутся из пула никак не решает проблемы, которые решает нетти, та же 10к problem.
Какую именно проблему вы пытаетесь решить? Если вы заблокировали все рабочие потоки в томкате, то вы так же заблокируете потоки и с нетти
Использование nio коннектора использует все тот же пул тредов для вызова твоих контроллеров и также блочит если ты не future отдаешь
Понятно, что он использует пул, но ведь не с той же целью, что и томкат, worker group’ы и все такое, а томкат использует новый поток на каждый запрос, где нетти должен просто проходить по иветам, в теории даже в одном потоке может обрабатывать. И мой вопрос не про то, умеет ли томкат работать с future, а в том, может ли он работать без модели thread per request, а так как это сделано в нетти, допустим для того, чтобы решить 10k problem.
Мне кажется, вы не понимаете, как оно работает и просто повторяете "умные слова"
Мое мнение не умеет, чтобы сделать completablefuture в тот метод он заходит тредом из своего пула. Да конечно, ваша completableFuture может быть запущена в каком-нибудь event loop, но все же сам факт, что томкат не имеет собственного event loopа
Ну так да, поэтому и спрашиваю.
Вот я примерно так и представляла себе.
Ваше представление абсолютно верно. Можно сделать один воркер тред и сделать так чтобы у вас тред в контролере сразу запускал фьючу. (Но любой фильтр и прочая фигня из сервлет апи, может разрушить этот уютный мирок)
Об этом и речь, если все неблокирующе отдается в future то будет гуд
netty - nio (selector, channel) tomcat, jetty - io + async servlet Вот так можете запомнить, этих знаний достаточно
Чем acceptor'ы в томкате хуже? Точно так же принимают входящие соединения, кладут их в очередь, откуда их берут воркеры
В фильтрах обычно нет блокинг кода, но если я правильно помню и там можно прикрутить асинхронно через жопное апи
Почитала, звучит как классический Nio, а спринг по-дефолту использует это режим? Ну и полагаю, что если в этом режиме заблокировать поток, то будет та же беда, что и в нетти
Да вы правы. Посмотрел с какого-то момента оно действительно стало так же. Async i/o и backpressure support.
Когда netty догонет?
Это сложный вопрос =)
Обсуждают сегодня