Jetty 8.1.16
был выпущен в сентябре 2014 года, теперь его EOL (End of Life) , рассмотрите возможность использования версии Jetty, которая является актуальной, стабильной и поддерживаемой.(например, Jetty 9.4.12.20180830
)
Тот факт, что вы получаете java.util.concurrent.RejectedExecutionException
криков, имеет недостаточную конфигурацию пула потоков.
Ваша конфигурация пула потоков ЧРЕЗВЫЧАЙНО мала.
Это подходит только для аппаратной конфигурации с одним ядром, одним процессором и одним потоком.Зачем?ну, это потому, что конфигурация вашего процессора / ядра / потока определяет ваше поведение NIO и диктует минимальные требования к вашему пулу потоков.
На ноутбуке MacOS с 2009 года (почти 10 лет назад!) Вам потребовалось бы минимум 9 потоков только для поддержки одного соединения, выполняющего один блокирующий REST-запрос на этом оборудовании.
Вкл.современная система Ryzen Threadripper, для которой часто требуется минимальное число потоков 69, чтобы поддерживать одно соединение, выполняющее один блокирующий REST-запрос на этом оборудовании.
С другой стороны, ваша конфигурация вполне подходит дляRaspberry Pi Zero, и может поддерживать около 3 соединений, при этом на каждое соединение активен 1 запрос.
При такой конфигурации вы сможете обрабатывать только простые запросы в последовательном режиме, и ваше приложение не использует асинхронную обработку или асинхронную обработку I/ O поведения.Зачем?это потому, что даже типичная современная веб-страница требует минимального количества потоков около 40, из-за того, как браузеры используют ваш сервер.
ExecutorThreadPool
также является ужасным выбором для вашей ситуации (он подходит только для сред с высокой степенью одновременности, например, 24+ процессоров / ядер и с минимальной конфигурацией потоков выше 500, часто в тысячах).
Было бы лучше использовать стандартный QueuedThreadPool
, который гораздо более производительный для нижнего уровня и способен расти для удовлетворения спроса (и сокращать его с течением времени, чтобы снизить использование ресурсов при снижении спроса).
QueuedThreadPool
(в Jetty 9.4.x) также имеет защиту от неправильных конфигураций и предупредит вас, если конфигурации недостаточно для вашей конфигурации оборудования, выбранного вами набора функций в Jetty или вашей конкретной конфигурации в Jetty.
Если вы хотите отклонить соединения при нехватке ресурсов, попробуйте использовать DoSFilter
(или если вы хотите быть более осторожным, рассмотрите QoSFilter
).
Попытка ограничить использование через ThreadPool никогда не будет работать, так как для отклонения соединенияпоток необходим для его принятия (поток-получатель, по одному на каждый соединитель сервера), другой для обработки событий NIO (поток селектора, общий ресурс, обработка нескольких соединений), а другой - для обработки запроса (для возврата кода состояния http 503).
Если вы хотите реализацию в своем собственном коде (не Jetty), вы, вероятно, могли бы просто написать Filter
, который подсчитывает активные обмены (запрос и ответ) и выдает статус ответа 503, если число превышает некотороенастраиваемое число.
Но если вы сделаете это, вам, вероятно, следует принудительно закрыть все ответы.aka Connection: close
заголовок ответа и не разрешать постоянные соединения.