Что происходит, когда пул потоков WebContainer (WebSphere) полностью используется и получен новый запрос?
есть вопрос о WebSphere и ничего не может найти в документации...
Что происходит, когда пул потоков WebContainer полностью используется и получен новый запрос? Я говорю о ситуации, когда все используются, и мы достигли максимального размера пула потоков, что означает, что новый не может быть создан для обработки запроса.
будет запрос: - сбой немедленно, и ответ будет содержать какую-то ошибку? - Была будет как-то "очередь" на запрос дано срок и обработать его, когда один из потоков возвращается в бассейн? Какая-то ошибка/тайм-аут все еще может произойти, если время ожидания слишком долго? - Будет ли "очередь" запроса бесконечно, и тайм-аут может произойти только на стороне пользователя (веб-браузер/приложение)?
1 ответов
точное поведение, вероятно, недокументировано, так что детали могут быть изменены между выпусками, чтобы улучшить поведение. Вероятно, вы можете сделать вывод о поведении, глядя на javacores или собирая информацию из различных документов, например, раздел BoundedBuffer этого Поваренная книга производительности IBM WebSphere Application Server документ:
буфер запроса пула потоков по существу является отставанием перед пул потоков. Если пул потоков имеет максимальный размер и все нити посланы, то работа будет очереди в requestBuffer. Максимальный размер requestBuffer равен пулу потоков максимальный размер, однако, если единица работы выполняется в потоке пул с режимом блокировки EXPAND_WHEN_QUEUE_IS_FULL_ERROR_AT_LIMIT или EXPAND_WHEN_QUEUE_IS_FULL_WAIT_AT_LIMIT, то максимальный размер ThreadPoolMaxSize * 10. Когда requestBuffer заполняется, то Wsvr0629i выдается (хотя только в первый раз это происходит на JVM запуск для пула потоков). Когда requestBuffer заполнен, работа будет либо ждать или бросить ThreadPoolQueueIsFullException, в зависимости от единица работы выполнена.
на практике это означает, что после того, как потоки maxThreads заняты выполнением работы, дополнительные запросы maxThreads будут поставлены в очередь в ограниченном буфере, и когда этот буфер заполнен, поток сокета будет блокировать, пока он не сможет поставить работу в очередь, что означает, что далее входящие запросы будут заблокированы до тех пор, пока поток не станет доступным и не освободит место в ограниченном буфере.