Я поддерживаю устаревшее приложение другого производителя.
Это приложение 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 секунд.После внесения этого изменения оно снова заработало.
Не ясно, было ли это каким-то образом сброшено или сброшено, или у меня было какое-то состояние гонки.