Я отвечаю за поддержку устаревшего приложения, работающего на Glassfish.Точная версия - «GlassFish Server Open Source Edition 3.1.2.2 (сборка 5)».
У меня есть два других приложения, взаимодействующих со Glassfish, которые сообщают об ошибках «недоступен сервис» в следующих формах:
- Apache с отчетами mod_jk
errno=110 - Directвызовы API-интерфейса SOAP из другого приложения, которое направляет напрямую в Glassfish отчеты HTTP 503 «исключение службы недоступно»
Общий совет для этих ошибок заключается в том, что приложение плохо настроено или занято или просто нетразвертывается.Мне нужно больше информации, чтобы определить, на каких аспектах приложения или хостинга Glassfish я должен сосредоточиться в первую очередь.
Журналы приложений в server.log для приложения, работающего в Glassfish, выглядят исправными.Они не регистрируют какие-либо исключения или неисправности.Журналы доступа Glassfish также выглядят здоровыми.Журналы доступа необычны тем, что они только регистрируют запросы, поступающие из пользовательского интерфейса через Apache + mod_jk, но не регистрируют вызовы SOAP UI.
Чтобы решить эту проблему, я думаю, что мне нужно увидеть файл журнала Glassfish, в котором сообщается об одном или нескольких из следующих действий:
- Когда 503 или аналогичный «недоступен"или" Я занят "ошибка, возвращаемая вызывающей стороне
- Когда достигается предел соединения
- Когда исчерпан пул потоков
Я надеюсьдля ведения журнала, в отличие от мониторинга.Я хочу статическую запись о проблеме.
Есть ли у Glassfish такие возможности регистрации?Если да, то как я могу их включить?
Если Glassfish не имеет этих возможностей, какие еще варианты я должен рассмотреть, чтобы получить информацию о симптомах, которые я вижу?
Обновление # 3
У меня ведется регистрация уже неделю.Никаких подробностей, которые я могу видеть там.
Нам пришлось перезапустить службу по другим причинам.После перезагрузки проблема проясняется.Мне не нравятся профилактические перезапуски.
Update # 2
Я думаю, что мне нужно больше регистрации от Grizzly.На основе этого SO потока Grizzy контролирует HTTP-соединения, а затем передает их GF.Поэтому, если я получаю 503, которая не попадает в журналы моего приложения, она должна быть получена от Grizzly.Предполагая, что мое понимание верно, как я могу заставить Grizzy регистрировать, когда он возвращает 503?
Обновление # 1
Я включил мониторинг для пулов потокови службы http.
Настройки мониторинга: 
Статистика сервера: 
Это статистика для прослушивателя HTTP, который обслуживает мои веб-сервисы: 
Я думаю, что страница статистики http pool говорит мне, что у меня было довольно много подключений в очереди и чтоМне нужно увеличить размер пула http-соединений, но не пул потоков.