Understanding Google Cloud Tasks Timing

Google Cloud Tasks offer a good solution for controlling workflows in our backend infastructure, increasing load peaks resilency while keeping costs controlled.

Such a powerful solution requires a careful configuration to properly work, specially when dealing with task retrying policy. This feature is basically controlled by a set of properties described in the Google Cloud documentation and quickly described here:

minBackoff: Elapsed time in seconds, from the initial task execution, that defines the lower limit of the incremental retry time window. The first retry will occur minBackoff seconds after the initial task execution.
maxBackoff: Elapsed time in seconds, from the initial task execution, that defines the higher limit of the incremental retry time window. After reaching maxBackoff the retry time will not increment, and retries will occur every maxBackoff seconds.
maxDoublings: Number of times that minBackoff will be doubled (multiplied by two) in order to be used as ellapsed time between retries. maxBackoff takes precedence over maxDoublings.
maxRetryDuration: Time in seconds to retry running failed tasks. Tasks failing after maxRetryDuration seconds AND being retried maxAttemps times (both conditions) will be discarded.
maxAttemps: Number of times a task execution is (re)tried. Note that if a task fails, it will be retried maxAttemps-1 times, since the first task execution must be also considered as an attempt. As previously said, tasks failing after maxRetryDuration seconds AND being (re)tried maxAttemps times (both conditions) will be discarded.

These properties can be seen in action in the next example diagram, in which they are set with these values:

minBackoff: 1 second
maxBackoff: 90 seconds
maxDoublings: 5 times
maxRetryDuration: 600 seconds (10 minutes)
maxAttempts: 21 times

Comentarios

Entradas populares de este blog

Linting C# in Visual Studio Code

Though very usual in programming environments as Javascript/Typescript, linting , or analyzing code for enforcing a set of coding style rules, is not usually present in the .NET based environments. Rule enforcing is really useful when working on team shared codebases in order to keep them coherent, what in last term reduces both development times and coding errors. A linting example Maybe a practical example would be helpful for explaining what linting is to the newcomers (feel free to go on if you aren't). Let's imagine you are a new member in a C# development team that has well established set of coding style rules. Instead (or apart) of putting them in a document, they've adopted a tool that checks these rules during the code building process. Your first code is such ambitious as this: namespace HelloWorld { using System; public class Program { public static void Main(string[] args) { Console

ESlint: Ignore unused underscore variables

Some naming conventions promote the use of the underscore character (" _ ") for those variables that must be declared but are not being used. One common case is that in which a function signature contains some variables that will not be used, as for instance the Express error handlers: app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!'); }); In the above example only the arguments err and res are being used, though all four must be defined in the handler signature. Thus, following the naming convention of using underscores for those unused variables, we could recode it as: app.use(function(err, _, res, __) { console.error(err.stack); res.status(500).send('Something broke!'); }); Though it makes the function more readable, it comes with a problem if using ESlint: it will blame by declaring unused variables. error '_' is defined but never used error '__' is define

Using Bitbucket app passwords with git on MacOS (OSX)

Learn how Bitbucket passwords are stored by git on MacOS.

The Modern Programmer

Buscar este blog