GAE/P: реализация экспоненциального отклика для вызовов RPC

Question

Я знаю, что экспоненциальное отключение - это хорошо, когда вызовы RPC терпят неудачу. До сих пор в моем GAE/P приложении Я выполнил экспоненциальную выдержку с помощью очереди задач:

deferred.defer(function_that_makes_RPC_call) 

Если функция, которая делает вызов RPC вызывает исключение, то экспоненциальные потери мощность из очереди задач заботятся о ней , и мне не о чем беспокоиться.

Проблема, однако, заключается в том, что deferred.defer сам по себе является вызовом RPC, который может выйти из строя! Иногда я получаю эту ошибку:

DeadlineExceededError: The API call taskqueue.BulkAdd() took too long to respond and was cancelled.

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

Подумываю поставить обертки вокруг deferred.defer, который реализует экспоненциальную выдержку, используя backoff, как это:

@backoff.on_exception(backoff.expo, 
         (exception1, exception2, ...), 
         max_tries=8) 
def defer_wrapper(function_that_makes_RPC_call): 
    deferred.defer(function_that_makes_RPC_call) 

Здесь декоратор реализует отсрочку, где повтор происходит, когда один из перечисленных исключений (например, exception1, exception2, ...) поднимается

пару вопросов по этому поводу:.

1. это хороший Soluti для реализации экспоненциального отсрочки?
2. Какие исключения мне нужно перечислить? Все, кроме DeadlineExceededError?

Я знаю, что это несколько излишним иметь свою собственную экспоненциальную выдержку, а затем представить в очередь задач, но я имею в виде, что deferred.defer должны терпеть неудачу реже, чем другие RPC вызовов, и я хотел бы ответить на запросите как можно скорее.

Answer 1

В частности для DeadlineExceededError в попытке установить вложенную задачу, я просто делаю повторные попытки back2back вместо использования экспоненциального отсрочка - попытки будут разнесены на 5 сек друг от друга из-за истечения срока действия крайнего интервала, что дает максимум из 12 попыток до того, как сам запрос достигнет своего крайнего срока.

Возможно, это хорошая идея для других типов сбоев.