Защита от заклинивания WebLogic

По умолчанию WebLogic убивает потоки после 15 минут (600 с), это контролируется параметром StuckThreadMaxTime. Однако я не могу найти более подробную информацию о том, как именно определяется «застревание». В частности:Защита от заклинивания WebLogic

В какой момент начинается отсчет 15 минут. Начало обработки запроса? Последний wait()-подобный метод? Что-то другое?
Это относится только к потокам обработки запросов или ко всем потокам? То есть может ли поток обработки запроса «избежать» этой защиты, создавая рабочий поток для выполнения длительной задачи? В частности, может ли он делегировать ответ на такого работника без 15-минутного обратного отсчета?

My usecase - это загрузка огромных файлов через систему разрешений. Поскольку пользователь должен быть аутентифицирован и иметь разрешения на просмотр файла, я не могу (или, по крайней мере, не знаю, как) оставить это на простом HTTP-сервере, например. Apache. И поскольку файлы могут быть огромными, загрузка могла (по крайней мере теоретически) занимать более 15 минут.

источник

2010-04-25 doublep

Weblogic делает NOT убивает потоки после StuckThreadMaxTime. Он не может этого сделать, сообщение является только информацией о состоянии, так что вы (то есть admin) знаете, что поток пересек 10 минут (600 секунд = 10 минут, а не 15)

Это настраиваемое значение.

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

Это относится ко всем нитям AFAIK - любая порожденная нить также будет работать по тем же правилам.

IMHO, Weblogic (или любой сервер приложений) - это не место для хранения и обслуживания больших файлов. Это идеально подходит для уровня веб-сервера - мы используем SunOne, на котором можно запустить сервлет загрузки файлов. В вашем случае вам понадобится Tomcat вместе с вашим Apache для оптимизации этого.

источник

2010-04-26 05:20:26 JoseK

ОК, но поскольку я знаю, что он может перераспределить все приложение, если слишком много застрявших потоков, нет? Возможно, у меня были смешанные вещи с тайм-аутом сеанса - у нас были некоторые проблемы с этим в прошлом. О файлах - приложение настолько велико и багги, что нет времени тратить на оптимизацию, поскольку всегда есть более насущные проблемы. – doublep

Сервер перестает отвечать на новые запросы, если слишком много застрявших потоков, но в вашем случае они не «застревают», а обрабатывают длинные запросы. Лучший подход - предоставить FileDownloadServlet собственный пул потоков выполнения - на WL10 это будет выделенный WorkManager. Это гарантирует, что любые потоки, затронутые или затронутые при загрузке, не будут влиять на остальную часть обработки стандартных запросов сервера. см. здесь - http://download.oracle.com/docs/cd/E11035_01/wls100/config_wls/self_tuned.html#wp1059038. Вы можете определить политику отправки для этого сервлета. – JoseK

Благодарим вас за ответ и разъяснения. – doublep

Документация WorkManager WLS10 может вызвать некоторые реальные царапины. См. 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 из подсчитываются против неисправного состояния сервера.

источник

2011-01-21 21:54:02

Только то, что я искал, спасибо! –

Защита от заклинивания WebLogic

ответ

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