Защита от заклинивания резьбы WebLogic
По умолчанию WebLogic убивает потоки после 15 минут (600 с), это контролируется параметром StuckThreadMaxTime
. Однако я не могу найти более подробную информацию о том, как именно определяется "застревание". В частности:
- В какой момент начинается отсчет 15 минут. Начало обработки запроса? Последний
wait()
-подобный метод? Что-то еще?
- Используется ли это только для потоков обработки запросов или для всех потоков? То есть может ли поток обработки запроса "избежать" этой защиты, создавая рабочий поток для выполнения длительной задачи? В частности, может ли он делегировать ответное письмо такому работнику без обратного отсчета 15 минут?
My usecase - это загрузка огромных файлов через систему разрешений. Поскольку пользователь должен быть аутентифицирован и иметь разрешения на просмотр файла, я не могу (или, по крайней мере, не знаю, как) оставить это на простом HTTP-сервере, например. Apache. И поскольку файлы могут быть огромными, загрузка может (по крайней мере теоретически) занимать более 15 минут.
Ответы
Ответ 1
Weblogic делает НЕ убивать потоки после StuckThreadMaxTime
. Он не может этого сделать, сообщение является только информацией о состоянии, так что вы (то есть admin) знаете, что поток пересек 10 минут (600 секунд = 10 минут, а не 15)
Это настраиваемое значение.
Таймер запускается, когда поток начинает обрабатывать запрос на сервере. Нить не будет убита, но будет продолжать обработку до завершения операции. поэтому в вашем случае вам не нужно беспокоиться о том, что поток убит, он только что проинформировал вас о времени, которое вы знаете в этом случае.
Он применяется ко всем потокам AFAIK - любой порожденный поток также будет работать по тем же правилам.
IMHO, Weblogic (или любой сервер приложений) не является местом для хранения и обслуживания больших файлов. Это идеально подходит для уровня веб-сервера - мы используем SunOne, на котором можно запустить сервлет загрузки файлов. В вашем случае вам понадобится Tomcat вместе с вашим Apache для оптимизации этого.
Ответ 2
Документация WMS10 WorkManager может вызвать некоторые реальные сбои в работе. См. http://blogs.oracle.com/jamesbayer/2010/01/work_manager_leash_for_slow_js.html для пошагового примера того, как определить WorkManager для webapp в weblogic.xml и назначить определенный сервлет, чтобы использовать его.
Добавляя к этому примеру, вы можете добавить <ignore-stuck-threads>true</ignore-stuck-threads>
в определение <work-manager>
, которое должно препятствовать тому, чтобы потоки, работающие для этого WorkManager, подсчитывались против состояния отказавшего сервера.