Защита от заклинивания резьбы 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, подсчитывались против состояния отказавшего сервера.