istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix(retry): add default behavior about retry (#7328) 

Link to https://github.com/istio/istio/issues/20547
This commit is contained in:
Davin Kevin 2020-05-15 17:02:23 +02:00 committed by GitHub
parent bb8275a963
commit cfbd480166
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/en/docs/concepts/traffic-management/index.md
View File

@ -666,8 +666,8 @@ availability and application performance by making sure that calls don’t fail
permanently because of transient problems such as a temporarily overloaded
service or network. The interval between retries (25ms+) is variable and
determined automatically by Istio, preventing the called service from being
overwhelmed with requests. By default, the Envoy proxy doesn’t attempt to
reconnect to services after a first failure.
overwhelmed with requests. The default retry behavior for HTTP requests is to
retry twice before returning the error.
Like timeouts, Istio’s default retry behavior might not suit your application
needs in terms of latency (too many retries to a failed service can slow things

4
content/pt-br/docs/concepts/traffic-management/index.md
View File

@ -674,8 +674,8 @@ availability and application performance by making sure that calls don’t fail
permanently because of transient problems such as a temporarily overloaded
service or network. The interval between retries (25ms+) is variable and
determined automatically by Istio, preventing the called service from being
overwhelmed with requests. By default, the Envoy proxy doesn’t attempt to
reconnect to services after a first failure.
overwhelmed with requests. The default retry behavior for HTTP requests is to
retry a call twice before sending back the error.
Like timeouts, Istio’s default retry behavior might not suit your application
needs in terms of latency (too many retries to a failed service can slow things