Как узнать, включена ли для конкретной конечной точки поддержка активности в Spring Boot?

У меня есть приложение Spring Boot с несколькими конечными точками, объявленными следующим образом:

@RestController
public class MyRestController {

    @PostMapping("/someRequest")
    public void doSomething(final @RequestBody MyRequest request) {
       // ...
    }

}

Как я могу узнать, включен ли сокет, используемый этим контроллером, TCP keepalive? на или нет?

Обновление 1: я запустил приложение с libdontdie, т.е. е. sudo DD_DEBUG=1 DD_TCP_KEEPALIVE_TIME=4 DD_TCP_KEEPALIVE_INTVL=5 DD_TCP_KEEPALIVE_PROBES=6 LD_PRELOAD=/usr/lib/libdontdie.so java -jar myapp.jar --spring.config.location=myapp-config.yaml &. Нужно подождать до завтра, чтобы увидеть, работает ли он или нет.


person Mentiflectax    schedule 20.02.2020    source источник
comment
если вы используете springboot с tomcat и свойствами по умолчанию, параметры поддержания активности имеют значение true. docs.spring. io/spring-boot/docs/current/reference/html/   -  person Alejandro Venegas    schedule 20.02.2020
comment
Извините, что значит не работает после долгого бездействия? Конечная точка должна работать в любое время, пока сервер запущен и работает. В чем проблема и как это связано с keepalive?   -  person s7vr    schedule 02.03.2020
comment
@ user2683814 Эта конечная точка используется веб-перехватчиком другого приложения (JIRA). Допустим, я запускаю свое приложение. Когда JIRA отправляет запрос моему приложению сразу после запуска, оно работает (запрос получен и обработан). Затем я позволяю моему приложению работать в течение многих часов, в течение которых оно не получает никаких запросов. Затем JIRA отправляет запрос на эту конечную точку. Этот запрос не обрабатывается моим приложением. Он обрабатывается только после перезапуска приложения.   -  person Mentiflectax    schedule 02.03.2020
comment
К вашему сведению: приложение работает на Ubuntu 18.04 в облаке AWS (EC2). Вполне возможно, что проблема связана с ОС.   -  person Mentiflectax    schedule 02.03.2020
comment
Хорошо. В логах есть что-нибудь? Предполагая, что ваше приложение никогда не получало второй запрос, это может быть что-то на сетевом уровне. Вы используете какие-либо службы обнаружения, такие как консул или эврика посередине? у вас есть какие-либо проверки работоспособности, настроенные для приложения, сканируемого каким-либо внешним монитором?   -  person s7vr    schedule 02.03.2020
comment
@user2683814 user2683814 Re Используете ли вы какие-либо службы обнаружения, такие как консул или эврика посередине? настроены ли у вас какие-либо проверки работоспособности приложения, сканируемого каким-либо внешним монитором?: нет на оба вопроса.   -  person Mentiflectax    schedule 02.03.2020
comment
Спасибо. Я до сих пор не думаю, что на данный момент это связано с поддержкой tcp. Не могли бы вы подтвердить, что ваше приложение все еще работало, когда пришел второй запрос? Если нет, проблема может быть связана с вашим приложением. Пробовали ли вы профилировать свое приложение и посмотреть, выполняются ли требования приложения к памяти и нет ли утечек памяти? Я не знаком с аспектом aws, поэтому это тоже может быть проблематично. Если у вас есть журналы aws, вы также должны проверить их.   -  person s7vr    schedule 02.03.2020
comment
Можете ли вы нарисовать грубую картину того, как выглядит ваше приложение? Где и как размещается этот контроллер? Как это называется? Какие журналы вы видите (как приложения, так и aws), когда запрос POST получен после того, как предположительно конечная точка «умерла»?   -  person Saif Asif    schedule 03.03.2020
comment
Также какой сервер у вас работает под капотом через весеннюю загрузку? У вас есть какая-то пользовательская логика/конфигурация загрузки сервлета?   -  person Saif Asif    schedule 03.03.2020


Ответы (2)


Вполне возможно, что происходит одно из следующего. Это может быть не связано с keepalive.

Причина

  1. Ваш ресурс AWS столкнулся с холодным запуском или переходом в спящий режим из-за простоя ЦП. Это может быть связано с AWS
  2. Ваша конечная точка /someRequest зависит от некоторых нижестоящих ресурсов, таких как база данных, другая служба отдыха, или может быть связана с тем, что ввод-вывод находится в состоянии ожидания.
  3. Если он подключается к базе данных, убедитесь, что у вас включено повторное подключение. Это может зависеть от того, как вы настроили соединение. См. Spring теряет соединение с БД и не восстанавливается и не переподключается, как это сделать в вашей ситуации.

Рекомендация решить

  1. Проверьте работоспособность экземпляра на консоли AWS и посмотрите, не попал ли он в режим ожидания. Попробуйте перевести узел в IDLE.
  2. Используя Spring Boot Actuator, включите проверку работоспособности нижестоящих зависимостей и убедитесь, что ваша работоспособность в порядке, прежде чем выполнять какой-либо вызов API. См. https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html
  3. Я не хочу рекомендовать это, но все ваши вышеперечисленные параметры высыхают, затем создайте фиктивную конечную точку, например /info или /health, и продолжайте периодически ее опрашивать. Это не очень хорошее решение, но в большинстве случаев оно сработает.
person reflexdemon    schedule 04.03.2020

Опрос - это решение. Продолжайте опрашивать его после определенного интервала.

person vaibhavkhot    schedule 08.03.2020