Расчетное время выполнения задачи в очередях AppEngine Push из-за отсутствия синхронизации часов сервера

Очереди push-уведомлений AppEngine позволяют планировать задачи для будущего выполнения, если они добавляются с помощью TaskOptions.etaMillis(...) вариант. Этот метод ожидает параметр long, который указывает время выполнения задачи в абсолютных миллисекундах, точно так же, как возвращается System.currentTimeMillis().

Учитывая, что AppEngine не дает никаких гарантий синхронизации часов сервера, и часы могут отставать примерно на ЧАСЫ!!! (см. "Google I/O 2010 — Конвейеры данных с Google App Engine" в 0:36: 07), как это может быть надежным?

Рассмотрим следующий пример:

  • Приходит http-запрос и направляется экземпляру, часы которого опережают время на 30 минут.
  • Во время обработки запроса я хотел бы отложить некоторую пакетную обработку до фоновой задачи.
  • Я хотел бы, чтобы результаты были доступны для отчета пользователю в течение примерно 10 секунд.
  • Итак, я планирую задачу с расчетным временем прибытия System.currentTimeMillis() + 10,000.
  • Учитывая 30-минутный сдвиг часов, это ожидаемое время прибытия фактически соответствует 30 минутам и 10 секундам от текущего момента.
  • Таким образом, если задача сейчас обрабатывается другим экземпляром, она может быть приостановлена ​​более чем на 30 минут.
  • Излишне говорить, что для пользователя это будет выглядеть так, как будто мой сервис умер

Это как-то предотвращено в базовом API? Если нет, то как вообще могут быть полезны расчетные сроки выполнения задач? Разве ETA не должно быть указано как относительное время, а не как абсолютное, чтобы это работало?

Самое печальное, что на самом деле существует функция под названием TaskOptions.countdownMillis(...), который ожидает относительное время, но смотрит на исходный код, который в конечном итоге обрабатывает это значение, видно, что он просто преобразуется в абсолютный спецификация времени, основанная на том же крайне ненадежном System.currentTimeMillis().

Что еще хуже: если вы не укажете расчетное время прибытия или обратный отсчет, эта функция просто использует текущее системное время, а не 0, поэтому даже задача, которую вы ожидаете выполнить немедленно, может в конечном итоге быть отложенной на час или более!

Это какая-то серьезная ошибка или я что-то упустил?

Кроме того, то же самое должно применяться к аренде Задач в Очереди на вытягивание. , правильно?


person Markus A.    schedule 05.09.2013    source источник


Ответы (1)


Если вы установите обратный отсчет на 10 000 мс, то задача обычно будет выполняться примерно через 10 секунд, но иногда задача может быть задержана на несколько минут. Они предназначены для задач, которых не ждет конечный пользователь.

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

person Eric Willigers    schedule 06.09.2013
comment
Итак, если я правильно вас понимаю, моя обеспокоенность верна, и действительно может быть случайный случай, когда выполнение задачи значительно задерживается, но (а) это должно происходить редко, потому что в целом синхронизация часов не так уж плоха и (б) в любом случае очереди задач никогда не предназначались для обеспечения гарантии ETA и поэтому не должны использоваться для чего-либо критичного по времени? - person Markus A.; 06.09.2013