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>
retryOnConnectFailure: <boolean>
retryOnConnectTimeout: <boolean>retries: backoffMultiplier: <number> delay: <int> failOverOn5XX: <boolean> retries: <int> retryOnConnectFailure: <boolean> 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 |
| retryOnConnectFailure | false | true | If true retry when the connection to the target could not be established at all: refused, host unreachable, or timed out in the operating system. Nothing has been sent in that case, so this applies to every request method, including POST and PATCH. Such a failure can be transient, e.g. when the target's accept queue is momentarily full, so the retry goes to the same node when there is only one. Set to false to fail fast instead. | - |
| retryOnConnectTimeout | false | true | If true retry when the connection to the target could not be established within the connection timeout Membrane applies itself. 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, and a connect that runs into the operating system's own timeout is covered by retryOnConnectFailure instead. Set to false to fail fast. | - |