Сервлеты, многопоточность, как устроено?

Question

[ericcartman]

Добрый день,
Предположим написал сервлет ( или на спринге сделал веб сервис через @RequestMapping) и запускаю в Tomcat.
Предположим набижало 10к юзеров.

1. Томкат будет создавать 10к потоков? Или в очередь поставит, начиная с n-ого? в конфигах это прописывается?
   
2. Предположим сервлет лезет в БД. Как правильно делать? Connection Pool?
   
3. Как кэшировать данные, ну скажем первый сервлет в первом же запросе вытащил данные из БД, какую то общую часть для всех хотелось бы закешировать. Это делать в ServletContext? Если хочу использовать какой то кэш ну типа memcache допустим, то он будет расшарен между всеми экземплярами сервлета?
   
   
4. когда экземпляр сервлета заканчивает работу ( ну или выходит из метода помеченного @RequestMapping ) он уничтожается полностью? И нет возможности передать что-то другому экземпляру сервлета?
   
5. Всей много поточностью рулит контейнер сервлетов ( томкат) и самому создавать потоки в теле метода @RequestMapping крайне не рекомендуется? В каком случае надо там создавать потоки?
   
6. вся логика сервлета происходит в синхронном режиме? ну то есть я полез к БД тяжелым запросом, и все встанет колом? ( сервер перестанет реагировать на 10001 запрос клиента)? Как разрулить это? Неиспользовать апач/томкат, а юзать jetty / undertow / nginx ?
   
   

Большое спасибо! ( если есть толковая статья где это все разжевано - буду благодарен, но плз только не талмуд на 1000стр)

Answer 1

[Сергей Горностаев]

При запуске Tomcat создаст пул потоков и экземпляр сервлета. При поступлении запросов методы сервлета будут запускаться на потоках из пула. Сервлет не уничтожается до окончания работы сервера.

Потоки можно создавать самостоятельно, но зачем? Особенно при использовании Spring, который предоставляет целую кучу удобных высокоуровневых абстракций для удобной работы с асинхронными задачами.

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

Comments

[ericcartman]

Благодарю за ответ! Стало чуть яснее, правильно ли:

1. То есть объект сервлета существует в единственном экземпляре? Получается, если я сделаю поле и сохраню туда инфу, то она сохранится между вызовами?
   
2. Если есть тяжелый запрос к БД, то все встанет колом, когда в томкатовском пуле закончатся потоки?Как можно это обойти? Если я буду юзать скажем что-то асинхронное, ну Vert.x скажем, подниму где-нибудь несколько Verticl-ов и буду им асинхронно из сервлета слать сообщения с просьбой законнектиться в БД и вернуть потом результат, это рабочая схема? или это велосипед, и все делается проще и быстрее ( как примерно? в какую сторону смотреть? )
   

Спасибо!

[Сергей Горностаев]

ericcartman,

1. Да, но значение в поле должно быть потокобезопасным или последствия будут ужасными.
   
2. Надо очень постараться, чтобы написать запрос, который может привести к истощению пула, но такое возможно. Обычно такую проблему решают отправкой тяжёлых заданий в очередь, из которой другой процесс (возможно даже на другом сервере) выбирает задания и выполняет.
   

[ericcartman]

Обычно такую проблему решают отправкой тяжёлых заданий в очередь, из которой другой процесс (возможно даже на другом сервере) выбирает задания и выполняет

А поток, отправивший запрос в очередь, уходит обратно в пул на ожидание следующих клиентских запросов? И забывает про то, что он послал в очередь что-то? Тогда клиенту все же получить данные? Я имею ввиду, кто-то же должен получить / обработать результаты того тяжелого запроса, когда они наконец придут. А поток уже давно в пуле. Как обычно это решается ( я естественно погуглю, только задайте мне направление в какую сторону гуглить)
Спасибо!

[ericcartman]

вот нагуглил:

Клиент запустил задачу, можно спокойно хранить ссылку на фоновую задачу в самой сессии.

Это рабочее решение? или это велосипед/костыль?

[Сергей Горностаев]

ericcartman, и тут мы переходим от обсуждения сервлетов к обсуждению протокола http. Этот протокол проектировался под взаимодействие в режиме вопрос-ответ без сохранения состояния. Так его желательно и использовать. Клиент отправил запрос с тяжёлой задачей, получит ответ о том, что задача принята, а при следующем запросе может получить состояние выполнения или результат выполнения, но ожидать ответа без разрыва соединение не должен. Если же всё-таки необходимо взаимодействие с клиентом режиме реального времени, то можно использовать websocket'ы, но для них лучше подойдёт какой-нибудь асинхронный фреймворк, типа Netty или Vert.x.

[ericcartman]

обсуждению протокола http. Этот протокол проектировался под взаимодействие в режиме вопрос-ответ без сохранения состояния. Так его желательно и использовать.

Тогда вопрос: вот это решение:
https://ynovikov.wordpress.com/tag/%D0%B0%D1%81%D0...
В частности:

клиент открывает долгоживущее HTTP-соединение, которое хранится на сервере до того момента, пока сервер не будет готов отослать ответ обратно

Reverse AJAX избавляет нас от необходимости все время опрашивать сервер — соединение открывается один раз, и потом сервер сам отошлет ответ, когда будет что отсылать. Естесственно, когда с сервера придет ответ, нужно установить соединение заново.

Как соотносится с протоколом http ? Не очень правильно? Но все юзают это? или это костыль, который надо заменить на Jetty / Netty / Undertow / Vert.x ?

[Сергей Горностаев]

ericcartman, асинхронные сервлеты - это просто способ переложить нагрузку с одного пула потоков на другой. Может быть решением в случаях когда долгоживущих соединений 100, но принципиально ничего не меняет и завалит сервер на 1000 соединений.

Jetty и Undertow - такие же web-контейнеры, как Tomcat. А вот Netty и Vert.x работают на других принципах и способны обрабатывать 10 000 и более одновременных соединений, но за счёт увеличения сложности.

[ericcartman]

А вот Netty и Vert.x работают на других принципах и способны обрабатывать 10 000 и более одновременных соединений, но за счёт увеличения сложности.

Я правильно понимаю, что они устроены по типу Node.js ? То есть реактивное программирование используется?
Тогда как подружить Netty ( или Vert.x) с веб сервером / сервером приложений? Ну то есть все равно запрос от клиента идет по http, и надо на него ответить статикой / логикой / инфой из БД. Поскольку для клиента все должно быть через http
Какой-то фреймворк их уже подружил? Spring например 5.0 ?

[ericcartman]

Какой-то фреймворк их уже подружил? Spring например 5.0 ?

Я имею ввиду, чтобы поставил аннотацию на метод и вот уже у нас Netty где-то под капотом спринга все делает, принимает запросы асинхронно, а мы имеем дело только с помеченным аннотацией методом

[Сергей Горностаев]

ericcartman, реактивное программирование - это парадигма, то как ты пишешь код, а не как устроены фреймворки. Можно и сервлеты писать в реактивном стиле.
Netty и Vert.x - асинхронные фреймворки, в них вместо пула потоков, выполняющих блокирующиеся операции, используется один поток, который постоянно крутит цикл событий, в котором выполняются неблокирующиеся операции.
Обычно, весь серверный код пишется или синхронным на сервлетах или асинхронным на Netty, без дружбы. Изредка основная логика пишется на сервлетах, а Netty обрабатывает только websocket-соединения. У меня в таком случае синхронный и асинхронный код обменивались данными через очередь.
У Spring'а есть MVC, который работает поверх сервлетов, и есть WebFlux, который работает поверх Netty. Два отдельных мира.

[Сергей Горностаев]

ericcartman,

Я имею ввиду, чтобы поставил аннотацию на метод и вот уже у нас Netty где-то под капотом спринга все делает

Нет, так не бывает. Хочешь обрабатывать множество одновременных соединений, готовься к трудностям.

[ericcartman]

Спасибо, буду рыть WebFlux!

WebFlux, который работает поверх Netty

а это не дружба? то есть нет такого удобства, как у MVC с сервлетами, когда поставил @RequestMapping и сам сервлет под капотом где-то, а ты радуешься жизни имея дело только с 1м методом?

Можно и сервлеты писать в реактивном стиле.

Это req.startAsync? или что-то другое ( я нагуглю, Вы только скажите в какую сторону гуглить)
И еще вопрос: тогда получается, в скором времени сервлеты отомрут вообще?

[Сергей Горностаев]

ericcartman, у WebFlux узкая область применения, он хорошо подходит для разработки REST-сервисов, но сайт на нём не напишешь.

Гуглить в сторону реактивного манифеста, Java Stream API, Spring Reactor и т.п.

Сервлеты не отомрут. У классического синхронного MVC куда большая востребованность в web-разработке, чем у асинхронных подходов.

[ericcartman]

Сергей Горностаев,

асинхронные сервлеты - это просто способ переложить нагрузку с одного пула потоков на другой

И это такое в сервлетах 3.0 безобразие? Рекламируется, как асинхронный, а на деле просто новый поток стартуют, да? Ну и не разрывают соединение, пока стартанутый поток работает.

[Сергей Горностаев]

ericcartman, в этом нет ничего страшного, в большинстве случаев это подходящее решение.

[ericcartman]

Сергей Горностаев, а если так:
Jetty has good support for asynchronous request pr...

public class AsyncServlet extends HttpServlet {
    private static String HEAVY_RESOURCE 
      = "This is some heavy resource that will be served in an async way";
 
    protected void doGet(
      HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {
  
        ByteBuffer content = ByteBuffer.wrap(
          HEAVY_RESOURCE.getBytes(StandardCharsets.UTF_8));
 
        AsyncContext async = request.startAsync();
        ServletOutputStream out = response.getOutputStream();
        out.setWriteListener(new WriteListener() {
            @Override
            public void onWritePossible() throws IOException {
                while (out.isReady()) {
                    if (!content.hasRemaining()) {
                        response.setStatus(200);
                        async.complete();
                        return;
                    }
                    out.write(content.get());
                }
            }
 
            @Override
            public void onError(Throwable t) {
                getServletContext().log("Async Error", t);
                async.complete();
            }
        });
    }
}

Примерно эти трудности Вы имели ввиду, когда говорили:

Нет, так не бывает. Хочешь обрабатывать множество одновременных соединений, готовься к трудностям.

[Сергей Горностаев]

ericcartman, нет, я имел ввиду, что пример "Hello Websockets" на Netty - это три сотни строк java-кода с ручным управлением памятью и ручной установкой http-заголовков в ответе. Забыл освободить буфер - приложение завалится. Неправильно оформил библиотечный вызов - приложение повесится. Неправильно подсчитал размер буфера - приложение или повесится, или завалится, или разбудит Древних, в зависимости от положения звёзд и фазы луны.

[ericcartman]

Сергей Горностаев, Понятно, спасибо!
Подскажите еще, вот Вы написали допустим все это на Netty, все учли, все правильно, допустим. А в базу данных идем все равно синхронно? Я понимаю, что это уже офф-топ, но сейчас есть какие то решения для хождения в БД асинхронно? ( ну в самые распространенные бд, MySql, PostgreSQL, Mongo)
И если они не дают асинхронного доступа, значит все эти асинхронные технологии ( Netty, Node.js, Go) в пользу бедных?
Или тогда хождение в БД делать отдельным сервисом, и ставить запросы к нему из слоя сервисов в очередь ( типа ActiveMQ, RabbitMQ ну или Kafka для особо замороченных)
Спасибо

[Сергей Горностаев]

ericcartman, на сегодняшний день доступ к БД в Java существует только синхронный. Асинхронный JDBC должен появится в сентябре. Пока в Netty эту проблему решают использованием специального EventExecutorGroup, который запускает блокирующиеся операции в отдельных потоках из фиксированного пула.