Flute's HttpSource: сервер Jetty multithread?

Question

Я немного искал Flume's HttpSource internals, пытаясь выяснить, как используется сервер Jetty.

Я видел, что используется один элемент списка соединителей; этот соединитель будет прослушивать входящие соединения Http на сконфигурированном хосте и порту Http. Затем создается контекст для корневого пути, и в этот Контекст добавляется HttpServlet, содержащая логику, которая должна быть выполнена при получении соединения. Наконец, запускается сервер Jetty.

Connector[] connectors = new Connector[1]; 

if (sslEnabled) { 
    SslSocketConnector sslSocketConnector = new HTTPSourceSocketConnector(excludedProtocols); 
    ... 
    connectors[0] = sslSocketConnector; 
} else { 
    SelectChannelConnector connector = new SelectChannelConnector(); 
    ... 
    connectors[0] = connector; 
} 

connectors[0].setHost(host); 
connectors[0].setPort(port); 
srv.setConnectors(connectors); 

try { 
    org.mortbay.jetty.servlet.Context root = new org.mortbay.jetty.servlet.Context(srv, "/", org.mortbay.jetty.servlet.Context.SESSIONS); 
    root.addServlet(new ServletHolder(new FlumeHTTPServlet()), "/"); 
    HTTPServerConstraintUtil.enforceConstraints(root); 
    srv.start(); 
    ... 

Вопрос в том, видел ли описанный выше вариант: создает ли такой сервер Jetty поток для каждого входящего соединения Http? Или же уникальный HttpServlet обслуживает все запросы по очереди последовательно?

Спасибо за помощь!

Answer 1

Первое из примечаний: org.mortbay.jetty означает, что вы используете очень старый вариант Jetty. Вероятно, Jetty 5 или Jetty 6. Это были EOL (конец жизни) еще в 2010 году (и ранее).

Назад в Jetty 6 дней, был использован ThreadPool, который использовался по требованию, и в зависимости от вашего типа Коннектора он либо привел бы к потоку на соединение (так называемые блокирующие разъемы), либо нить на выбор nio (в этом случае ваши 1 соединения имеют много потоков на протяжении всего времени соединения, но не более 1 активного соединения).

Начиная с Jetty 8 и асинхронного сервлета, эта модель потоковой обработки была реорганизована для поддержки асинхронного поведения обработки запроса.

С Jetty 9 все блокирующие разъемы были отброшены в пользу поддержки полностью асинхронной обработки запроса, его входных потоков и его выходных потоков.

Текущая модель предназначена для ThreadPool потоков, которые будут использоваться по требованию, только в случае необходимости при подключении (это может быть обработка запроса или ответ или чтение содержимого тела запроса или запись ответное содержимое тела или активная потоковая передача websocket и т. д.)

Эта модель предпочтительна для поддержки SPDY и HTTP/2, где у вас есть несколько запросов на физическое соединение. Но знайте, что в этих моделях вполне возможно иметь несколько активных потоков на физическое соединение, в зависимости от поведения ваших сервлетов.

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