With several backend nodes each attempt goes to the next node, so a failing node is skipped straight away. The delay applies only to a target with a single node, where it grows exponentially between attempts. Attempts spread over several nodes follow each other without a delay.
A retry follows a connection or IO error and HTTP 408, and optionally HTTP 500, 502, 503, 504 and 507. Methods that are not idempotent, such as POST and PATCH, are not repeated once the request may have reached the server.
Example Configuration
configuration:
httpClientConfig:
retries:
retries: 3
delay: 500
failOverOn5XX: true
configuration:
httpClientConfig:
retries:
retries: 3
delay: 500
failOverOn5XX: true
Syntax
retries:
backoffMultiplier: <number>
delay: <int>
failOverOn5XX: <boolean>
retries: <int>
retryOnConnectTimeout: <boolean>retries: backoffMultiplier: <number> delay: <int> failOverOn5XX: <boolean> retries: <int> retryOnConnectTimeout: <boolean>
Attributes
| Name | Required | Default | Description | Examples |
|---|---|---|---|---|
| backoffMultiplier | false | 2 | Multiplier applied to the delay after each retry (exponential back-off). | 1.5 |
| delay | false | 100 | Initial delay in milliseconds before the next attempt. Only applied when the target has a single node; with several nodes the attempts follow each other without a delay. | 1000 |
| failOverOn5XX | false | false | If true retry on HTTP 500, 502, 503, 504 and 507 responses (fail-over). | - |
| retries | false | 2 | Number of additional retry attempts after the initial call. A value of 0 or less disables retries, so only the initial call is made. | 5 |
| retryOnConnectTimeout | false | true | If true retry when the connection to the target could not be established within the connection timeout. No part of the request has been sent in that case, so this applies to every request method, including POST and PATCH. A timeout while reading the response is not covered by this and stays restricted to idempotent methods. Set to false to fail fast instead. | - |