Установить ограничение очереди через jetty.xml в Jetty 9 Maven Plugin

Question

Пул потоков в Jetty по умолчанию реализован с неограниченной очередью после заполнения пула потоков. Я бы поставил ограничение на размер очереди. Существует конструктор для BlockingArrayQueue, который принимает значение maxCapacity, но я не вижу способа вызвать его, используя jetty.xml. Начиная с Jetty 9, нет фильтра для threadpool в org.eclipse.jetty.server.Server, я могу получить ссылку на пул потоков, который уже был создан и изменен (см. this answer). И установщик для поля очереди в QueuedThreadPool выбрасывает UnsupportedOperationException, говоря, что использует инъекцию конструктора. Но это невозможно, если я могу только мутировать пул потоков, а не устанавливать новый экземпляр сервера. Попытка определить пул потоков в качестве конструктора arg дает следующее предупреждение:

2014-09-22 13: 15: 13.688: WARN: oejx.XmlConfiguration: main: Ignored arg: | 200501000 | 6000 | ложь |

Это с плагином Jetty Maven v9.2.2.v20140723. Вот конфигурация в моем pom.xml:

<configuration> 
     <jettyXml>${basedir}/jetty.xml</jettyXml> 
     <stopKey>x</stopKey> 
     <stopPort>7999</stopPort> 
     <requestLog implementation="org.eclipse.jetty.server.NCSARequestLog"> 
     <append>true</append> 
     </requestLog> 
     <webApp> 
     <war>${basedir}/target/app</war> 
     <contextPath>/app</contextPath> 
     </webApp> 
     <scanTargets> 
     <scanTarget>${basedir}/src/main/webapp/WEB-INF/</scanTarget> 
     </scanTargets> 
     <reload>manual</reload> 
    </configuration> 

Answer 1

Update: Конструктор сервера, как настроить пул потоков, к сожалению, you cannot configure the Server constructor from within jetty-maven-plugin. Это не подходит для плацдарма причала.

---

ThreadPool в Jetty 9 теперь настройки в экземпляре Constructor of the Server.

Используя XML, вы можете перенастроить его, это даже documented in the jetty.xml itself.

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

Вот удобная формула для салфеток.

Max Темы = (((количество CPU ядер) * 4) * (кол-разъем)) + (Максимальное количество одновременных запросов)

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

Думая, что вам нужно установить верхние границы производительности, является формой premature optimization.

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

Если у вас есть память или другие ресурсы, знайте, что установка Jetty по умолчанию работает нормально даже на Android 2.3 (Gingerbread) (примечание: Jetty 7 w/QTP), Android 4.4 (Jetty 9) и Raspberry Pi (Jetty 7 по 9).

И наконец, как установить размер очереди приема.

Настройка вашего ServerConnector (обычно находится в etc/jetty-http.xml)

<Set name="acceptQueueSize">40</Set> 

Значение по умолчанию 0, и относится к параметру backlog в ServerSocketChannel.bind(SocketAddress,int) вызова на самых низких уровнях.

Answer 2

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

Я думаю, что это настоящий вопрос, следующий подход.

Поскольку его невозможно переопределить размер пула по умолчанию или ввести его в Jetty Server. Мы написали пользовательский ServerConnector, в котором вы можете установить размер очереди или ваш исполнитель, если на то пошло.

jetty.addServerCustomizers((Server server) -> { 
    LinkedBlockingQueue<Runnable> queue = new LinkedBlockingQueue< (maxQueueSize); 
    ExecutorService exceutorService = 
     new ThreadPoolExecutor(minThreads, maxThreads, 1, 
      TimeUnit.HOURS, queue); 

    // extract host and port from existing connector... 
    String host = "0.0.0.0"; 
    int port = 1900; 
    for (Connector c : server.getConnectors()) { 
     if (c instanceof ServerConnector) { 
      host = ((ServerConnector) c).getHost(); 
      port = ((ServerConnector) c).getPort(); 
     } 
    } 


    ServerConnector connector = new ServerConnector(server, exceutorService, null, null, -1, -1, new HttpConnectionFactory()); 
    connector.setHost(host); 
    connector.setPort(port); 
    server.setConnectors(new Connector[] { connector }); 
} 

Против

1) Так как Jetty ожидает ThreadPool Queued, когда мы пытались то же самое, что используется, чтобы дать случайные результаты, где запуска сервера не оправдавших-несмотря на правильные конфигурации. Поведение не было предсказуемым.

2) Поскольку ExecutorService не реализует Threadpool, плагин сбора данных показателей для Jetty может работать неправильно.

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