CloudFoun dry уничтожает экземпляр сразу после запуска, но не завершает работу полностью - PullRequest
Новая
       62

CloudFoun dry уничтожает экземпляр сразу после запуска, но не завершает работу полностью

0 голосов
/ 09 июля 2020

У меня нет опыта работы с CloudFoun dry. Я знаю, как использовать его для подключения служб к приложению, а также для ведения войны, файлов журналов и т. Д. c. Так стандартно. Но когда дело доходит до конфигурации и поведения CloudFoun dry, мои знания заканчиваются.

Моя проблема в том, что сразу после запуска моего приложения и завершения New Reli c он ведет журнал с точки зрения того, что он использует как сборщик эт c. Ячейка CloudFoun dry останавливает экземпляр. Я использую весеннюю интеграцию, которая отключает все из-за сигнала, отключающего jvm. Я также отключил несколько логических значений в своей базе данных для некоторых заданий. До этого момента все работает, и все в порядке.

Как только все выключено, CloudFoun dry начинает уничтожать контейнер для текущего экземпляра. После этого в журнале написано, что уничтожение прошло успешно. Но приложение все еще работает так же хорошо, как и экземпляр. Мое приложение по-прежнему регистрирует некоторые вещи (которые не являются закрытыми заданиями) здесь и тогда, и экземпляр, кажется, все еще жив и не «обновляется».

Кто-нибудь знает, почему это происходит? Должен ли я реализовать в Spring что-то, что блокирует уничтожение экземпляра? Или это конфигурация CloudFoun dry, которую мне нужно сделать?

Одна странность в том, что это происходит только раз в одноранговую неделю. Каждую ночь со среды по утро четверга. Почти в то же время.

Изменить: вот журнал, в котором я удалил всю сенситивную информацию. 

   Some logs which indicate that the app is still running as expected.
   
   // I think this is the part where i gets interesting.
   2020-07-09T00:44:09.87+0200 [CELL/0] OUT Cell XXX requesting replacement for instance XXX
   2020-07-09T00:44:10.37+0200 [CELL/0] OUT Cell XXX creating container for instance XXX
   2020-07-09T00:44:12.17+0200 [CELL/0] OUT Cell XXX successfully created container for instance XXX
   
   Downloading droplet, starting the application and notice that it was shutted down unexpectedly. The indication for that is a flag in the database that hasn't been set to true which would happen during a proper shutdown.
   
   2020-07-09T00:45:14.70+0200 [CELL/0] OUT Container became healthy
   
   Some New Relic information which are not important for this question.
   
   2020-07-09T00:45:19.94+0200 [CELL/0] OUT Cell XXX stopping instance XXX
   
   This is the part where the application shuts down it's listeners and jobs.
   
   2020-07-09T00:45:25.70+0200 [APP/PROC/WEB/0] OUT Exit status 143
   2020-07-09T00:45:25.70+0200 [CELL/0] OUT Cell XXX destroying container for instance XXX
   2020-07-09T00:45:25.88+0200 [PROXY/0] OUT Exit status 137
   2020-07-09T00:45:26.07+0200 [CELL/0] OUT Cell XXX successfully destroyed container for instance XXX
   2020-07-09T00:49:36.17+0200 [APP/PROC/WEB/0] OUT 2020-07-09T00:49:36,178+0200 Some log entry which indicates that the app is still alive

После этого приложение все еще работает (оно не было перезапущено между ними) можно снова запустить все задания, установив флаг в значение true, которое было установлено в значение false в коде обработчика выключения, чтобы никакие новые задания не запускались, пока приложение завершает работу.

1 Ответ

0 голосов
/ 10 июля 2020

Теперь я знаю, в чем была проблема. Спасибо коллеге, который точно знал, что происходит, когда видел журналы.

CloudFoun dry создает новый экземпляр перед уничтожением старого, чтобы избежать простоев. Как только новый экземпляр заработает, он уничтожит старый. Приложение, работающее в новом экземпляре, по-прежнему получает сигнал выключения старого экземпляра и выполняет код в ловушке выключения. Это означает, что для флагов будет установлено значение false, чтобы остановить все задания при завершении работы приложения.

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

...