Приложение для обновления GAE, как избежать насильственной остановки длительного процесса?

Question

У меня есть приложения GAE, которые вызывают некоторый длительный процесс через другой модуль (управляемый basic_scaling).

Этот длинный процесс корректно обрабатывает DeadlineExceededError, но порождает метод отложенной функции, который впоследствии сохранит текущее состояние длительного процесса.

Сегодня я обнаружил, что когда я делаю appcfg.py -A <YOUR_PROJECT_ID> update myapp/, он прерывает длительный процесс. Просто остановитесь, не DeadlineExceededError (здесь идет моя надежда), ничего.

Есть ли какие-то события, вызванные GAE, перед остановкой приложения, которые позволят мне сохранить текущее состояние моего длительного процесса, записать данные в файлы (через s3, так немного) и переупорядочить процесс перезапустить позже? (или что-то вроде этого)?

Благодарим за помощь.

Answer 1

От Scaling types and instance classes, ручное и основное масштабирование по всей видимости, ведет себя одинаково от остановки экземпляра перспективной:

Как с ручным масштабированием, экземпляр, который останавливается AppCfg остановить или от Cloud Platform Console) имеет 30 секунд, чтобы завершить обработку запросов до того, как они будут принудительно завершены.

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

И от Shutdown:

Есть два способа для приложения, чтобы определить, является ли вручную масштабирование экземпляр собирается быть закрыты. Во-первых, метод is_shutting_down() из google.appengine.api.runtime начинает возвращать true. Второй (и предпочтительнее), вы можете зарегистрировать крюк выключения, как описано ниже.

Когда App Engine начинает закрывать экземпляр, существующие запросы данные 30 секунд, чтобы закончить, и новые запросы немедленно вернуться 404. Если экземпляр обрабатывает запрос, App Engine приостанавливает запрос и запускает выключение крюк. Если активного запроса нет, App Engine отправляет запрос/_ah/stop, который запускает крюк отключения. Запрос /_ah/stop обходит обычную логику обработки и не может быть обработан по коду пользователя; его единственная цель - вызвать крюк остановки. Если вы возбудите исключение в своем крючке выключения при обращении с другим запросом , он запустится в запрос, где вы сможете его поймать.

Если включена функция одновременных запросов, указав поточно: истинное в app.yaml (который по умолчанию), вызывая исключение из остановленных через крюка копии что исключение всех потоков.Следующий код пример демонстрирует основную выключение крюком:

from google.appengine.api import apiproxy_stub_map 
from google.appengine.api import runtime 

def my_shutdown_hook(): 
    apiproxy_stub_map.apiproxy.CancelApiCalls() 
    save_state() 
    # May want to raise an exception 

runtime.set_shutdown_hook(my_shutdown_hook) 

В качестве альтернативы, в следующем примере показано, как использовать метод is_shutting_down():

while more_work_to_do and not runtime.is_shutting_down(): 
    do_some_work() 
    save_state() 

Примечание: Важно признать, что остановки hook не всегда может запускаться до завершения экземпляра. В редких случаях может произойти сбой , который предотвращает запуск App Engine 30 секунд . Таким образом, мы рекомендуем периодически проверять состояние вашего экземпляра и использовать его в основном как кеш в памяти, а не , чем надежное хранилище данных.

Основываясь на моем предположении выше, я ожидаю, что эти методы также будут работать на ваш случай, попробуйте.

Answer 2

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

Всякий раз, когда я обновляю производственную версию своего приложения, я делаю это в новой версии. Я использую текущую дату для моего имени версии (например, 2016-05-13). Затем я перехожу к облачной консоли Google и делаю эту новую версию по умолчанию. Таким образом, старая версия продолжает работать параллельно.

Я задал аналогичный вопрос пару лет назад, что вы можете видеть here.