Приложение J2EE, работающее на Glassfish v3, не отвечает на запросы HTTP.Приложение регистрирует успех, но данные не передаются по HTTP - PullRequest
0 голосов
/ 25 октября 2018

Я поддерживаю устаревшее приложение другого производителя.

Это приложение J2EE, которое работает на Glassfish v3.1.2.2.Он имеет REST API, реализованный с использованием JAX-RS.У меня ограниченная видимость приложения и источника.

Симптомы:

  • делает HTTP-запрос к API REST
  • приложение имеет свою собственную систему аудита,это показывает успешный запрос
  • без ошибок в журналах GF
  • Журнал доступа GF отмечает, что запрос
  • 0 байтов возвращается из запроса к вызывающей стороне

Это происходит как для удаленных вызовов, так и для вызовов, выполненных с использованием curl на localhost.

Если мы выполняем одинаковые запросы к другому порту через HTTPS, они выполняются успешно.Мы не хотим переносить вызовы на этот другой порт, не зная причину.Они периодически терпели неудачу прошлой ночью, а теперь постоянно терпят неудачу сегодня.

Захват пакета запроса показывает: - издержки TCP / рукопожатие - запрос GET - один ACK от приложения обратно к вызывающей стороне - затем ничего после этого

Что вызовет Glassfish v3успешно обработать и обработать запрос HTTP, но не вернуть данные?

Есть ли в Glassfish v3 механизм для сброса или сброса прослушивателя HTTP и связанного с ним пула потоков?

Поскольку это происходит назапрос curl на том же сервере к localhost Я думаю, что могу исключить проблему с сетью.

Используемые порты напрямую связываются с Glassfish.Между вызывающим абонентом и сервером приложений нет прокси-сервера (например, Apache или Nginx).

Есть ли в Glassfish параметры ведения журнала или мониторинга, которые я должен включить, чтобы наблюдать, что делает прослушиватель HTTP по отношению к приложению исетевой стек?

Я запутал некоторые примеры, которые показывают симптомы:

Журнал доступа Glassfish:

"0:0:0:0:0:0:0:1" "NULL-AUTH-USER" "25/Oct/2018:11:21:02 -0500" "GET /api/obfuscated/by/me HTTP/1.1" 200 9002 

Ответ Curl для того же вызова:

*   Trying OFBBFUSCATED
* Connected to hostname.local (OFBBFUSCATED) port 11080 (#0)
> GET /api/obfuscated/by/me HTTP/1.1
> Host: hostname.local:11080
> User-Agent: curl/7.43.0
> Accept: */*
> Authorization: Basic asdfdsfsdfdsfsdafsdafsdafw==
>
* Empty reply from server
* Connection #0 to host hostname.local left intact

ОБНОВЛЕНИЕ Я изменил настройку тайм-аута для прослушивателя сети HTTP.Я увеличил его с 30 до 35 секунд, потому что я видел захват пакета, когда приложение отправляло FIN через 30 секунд.После внесения этого изменения оно снова заработало.

Не ясно, было ли это каким-то образом сброшено или сброшено, или у меня было какое-то состояние гонки.

1 Ответ

0 голосов
/ 31 октября 2018

Кажущейся основной причиной был высокий уровень ввода-вывода в системе, где выполнялись эти службы.Приложения обычно используют 50 МБ / с, новый процесс довел это использование до 250 МБ / с.Как только проблема ввода-вывода была решена, все ошибки HTTP исчезли и не вернулись.

...