2016-10-14 4 views
4

У меня есть несколько веб-приложений, работающих под одним контейнером Tomcat. Поскольку все они работают под одним коннектором Tomcat (как определено в файле server.xml), атрибуты, такие как maxConnections и maxThreads, управляют контейнером в целом. В результате одно приложение может потреблять все доступные потоки Tomcat, голодая другими приложениями потоков и делая их невосприимчивыми. Я хотел бы иметь возможность определять максимальные потоки HTTP на основе каждого контекста, чтобы это стало невозможным.Соединения Tomcat max для каждого контекста

Вот что я пытался до сих пор:

  1. Создайте пользовательский фильтр в приложении, которое отслеживает текущее значение счетчика потоков и ограничения дополнительных соединений. (Здесь есть фильтр: How to set limit to the number of concurrent request in servlet?). Я не уверен, что мне нравится это решение, поскольку оно не является полнофункциональным (поддержка атрибутов, таких как acceptCount, maxConnections, maxThreads и minSpareThreads), поскольку Tomcat по умолчанию предоставляет контейнер; и добавление в функции чувствует, что я пытаюсь построить то, что уже существует в Tomcat.
  2. Создайте отдельный соединитель Tomcat в файле server.xml для каждого контекста. У этого есть несколько проблем. Например, для каждого разъема требуется отдельный порт; это означает, что мне придется учитывать это в моей конфигурации apache. Во-вторых, я планирую регулярно добавлять дополнительные webapps; это означает изменение конфигурации, за которым следует перезапуск tomcat, который является подрывным для клиентов.

Неужели кто-нибудь еще сталкивался с чем-то подобным? Я чувствую, что должен быть рабочий процесс, поддерживаемый Tomcat, для выполнения того, что мне нужно.

+0

Я бы сказал, что вы прибили его. Это одна из причин, почему использование одного сервера приложений для управления пакетом приложений довольно устарело. И нет другого решения, определяющего собственный соединитель для каждого приложения. –

+0

@PaulWasilewski У вас есть какие-либо подробности о том, какой может быть более современный подход? Один экземпляр Tomcat для каждого приложения? – Staros

+1

@Staros, да, это будет один подход. Но с этим было бы трудно справиться.Вы должны использовать фреймворки, такие как Spring Boot, Dropwizard или Play, чтобы избавиться от вашего внешнего экземпляра сервера приложений и позволить серверу быть частью вашего кода. Взгляните на https://jaxenter.com/java-application-servers-dead-1-111928.html –

ответ

1

Я собираюсь опубликовать ответ, который был предоставлен мне из группы пользователей Tomcat: http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Semaphore_Valve (Семафорный клапан не является Tomcat 9, но был введен в Tomcat 6). Я экспериментировал с этим понятием, и я нашел следующие практические приложения:

  1. (непроверенная) Семафор клапан должен быть в состоянии быть вложены в элемент хоста в файле server.xml.
  2. (Протестировано) Файл [context-name] .xml может быть помещен внутри [tomcat-home]/conf/Catalina/localhost с клапаном, вложенным в элемент Context.

Это не обязательно решение, с которым я столкнулся, поскольку потребуется провести дополнительные испытания. Однако я думал, что добавлю это, поскольку это потенциальный ответ на проблему.

Update:
Как резюмировать, то SemaphoreValve был вариант, который рекомендовал мне через список рассылки пользователей Tomcat в качестве решения проблемы, которую я описал выше. Оказывается, это было проще реализовать, чем я ожидал. Добавление следующих строк в context.xml в каталоге/конф Tomcat сделал трюк:

<Valve className="org.apache.catalina.valves.SemaphoreValve" concurrency="10" fairness="true" />

Благодаря Марк Томас из группы Apache для подачи раствора.

+0

Опция SemaphoreValve (возможно) приемлема с блокировкой ввода-вывода (BIO), где у вас есть один поток для каждого соединения, но как насчет конфигурации без блокировки ввода-вывода (NIO)? А как насчет всех других функций, которые вы упомянули, которые предоставляются HTTP-коннектором? –

Смежные вопросы