La AWS SDK pour JavaScript v2 est arrivée end-of-support. Nous vous recommandons de migrer vers la [AWS SDK pour JavaScript version 3](https://docs.aws.amazon.com//sdk-for-javascript/v3/developer-guide/). Pour plus de détails et d'informations sur la façon de migrer, veuillez consulter cette [annonce](https://aws.amazon.com/blogs//developer/announcing-end-of-support-for-aws-sdk-for-javascript-v2/).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Réessayez la stratégie dans la v2 AWS SDK pour JavaScript
Un grand nombre de composants d'un réseau, tels que serveurs DNS, commutateurs, équilibreurs de charge ou autres, peuvent générer des erreurs à n'importe quel moment de la vie d'une requête donnée. La technique habituelle pour traiter ces réponses erronées dans un environnement réseau consiste à implémenter les nouvelles tentatives dans l’application cliente. Cette technique augmente la fiabilité de l'application et réduit les coûts opérationnels pour le développeur. AWS SDKs implémentez une logique de nouvelle tentative automatisée pour vos AWS demandes.
## Comportement de nouvelle tentative basé sur le recul exponentiel
La AWS SDK pour JavaScript v2 implémente une logique de nouvelle tentative utilisant un [ralentissement exponentiel avec une instabilité totale pour un meilleur contrôle](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/#Jitter) du flux. L’idée sous-jacente consiste à utiliser des temps d’attente progressivement plus longs entre les tentatives en cas de réponses d’erreur consécutives. La gigue (délai aléatoire) est utilisée pour empêcher les collisions successives.
### Test du délai de nouvelle tentative dans la version 2
Afin de tester le délai de nouvelle tentative dans la version 2, le code de [node\$1 modules/aws-sdk/lib/event \$1listeners.js](https://github.com/aws/aws-sdk-js/blob/master/lib/event_listeners.js#L588) a été mis à jour avec `console.log` la valeur présente dans le délai variable comme suit :
```
// delay < 0 is a signal from customBackoff to skip retries
if (willRetry && delay >= 0) {
resp.error = null;
console.log('retry delay: ' + delay);
setTimeout(done, delay);
} else {
done();
}
```
#### Retards de nouvelle tentative avec la configuration par défaut
Vous pouvez tester le délai pour n'importe quelle opération sur les clients du SDK AWS. Nous appelons `listTables` opération sur un client DynamoDB à l'aide du code suivant :
```
import AWS from "aws-sdk";
const region = "us-east-1";
const client = new AWS.DynamoDB({ region });
await client.listTables({}).promise();
```
Afin de tester les nouvelles tentatives, nous simulons `NetworkingError` en déconnectant Internet de l'appareil exécutant le code de test. Vous pouvez également configurer le proxy pour qu'il renvoie une erreur personnalisée.
Lors de l'exécution du code, vous pouvez constater que le délai de nouvelle tentative est dû à un recul exponentiel avec instabilité, comme suit :
```
retry delay: 7.39361151766359
retry delay: 9.0672860785882
retry delay: 134.89340825668168
retry delay: 398.53559817403965
retry delay: 523.8076165896343
retry delay: 1323.8789643058465
```
Comme retry utilise le jitter, vous obtiendrez des valeurs différentes lors de l'exécution de l'exemple de code.
#### Retards de réessai avec base personnalisée
La AWS SDK pour JavaScript v2 permet de transmettre un nombre de base personnalisé en millisecondes à utiliser lors du ralentissement exponentiel pour les nouvelles tentatives d'opération. La valeur par défaut est de 100 ms pour tous les services à l'exception de DynamoDB, où elle est de 50 ms.
Nous testons les nouvelles tentatives avec une base personnalisée de 1 000 ms comme suit :
```
...
const client = new AWS.DynamoDB({ region, retryDelayOptions: { base: 1000 } });
...
```
Nous simulons `NetworkingError` en déconnectant Internet de l'appareil exécutant le code de test. Vous pouvez constater que les valeurs du délai de nouvelle tentative sont plus élevées que lors de l'exécution précédente, où la valeur par défaut était de 50 ou 100 ms.
```
retry delay: 356.2841549924913
retry delay: 1183.5216495444615
retry delay: 2266.997988094194
retry delay: 1244.6948354966453
retry delay: 4200.323030066383
```
Comme retry utilise le jitter, vous obtiendrez des valeurs différentes lors de l'exécution de l'exemple de code.
#### Retards de nouvelle tentative grâce à un algorithme de réduction personnalisé
La AWS SDK pour JavaScript v2 permet également de transmettre une fonction d'annulation personnalisée qui accepte le nombre de tentatives et les erreurs et renvoie le temps de retard en millisecondes. Si le résultat est une valeur négative différente de zéro, aucune nouvelle tentative ne sera effectuée.
Nous testons une fonction de rétrogradation personnalisée qui utilise une rétrogradation linéaire avec une valeur de base de 200 ms comme suit :
```
...
const client = new AWS.DynamoDB({
region,
retryDelayOptions: { customBackoff: (count, error) => (count + 1) * 200 },
});
...
```
Nous simulons `NetworkingError` en déconnectant Internet de l'appareil exécutant le code de test. Vous pouvez constater que les valeurs du délai de nouvelle tentative sont des multiples de 200.
```
retry delay: 200
retry delay: 400
retry delay: 600
retry delay: 800
retry delay: 1000
```