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

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

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

Спасибо!

ericcartman,

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

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

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

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

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

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

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

обсуждению протокола 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 и более одновременных соединений, но за счёт увеличения сложности.

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

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

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

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

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

ericcartman,

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

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

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

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

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

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

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

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

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

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

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

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

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

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-заголовков в ответе. Забыл освободить буфер - приложение завалится. Неправильно оформил библиотечный вызов - приложение повесится. Неправильно подсчитал размер буфера - приложение или повесится, или завалится, или разбудит Древних, в зависимости от положения звёзд и фазы луны.

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

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