mirror of https://github.com/grpc/grpc.git
Merge pull request #7697 from ejona86/waitforready
Rename Fail Fast doc to Wait for Readypull/7936/head
commit
a3328aebe6
2 changed files with 15 additions and 15 deletions
@ -1,15 +1 @@ |
||||
gRPC Fail Fast Semantics |
||||
======================== |
||||
|
||||
Fail fast requests allow terminating requests (with status UNAVAILABLE) prior |
||||
to the deadline of the request being met. |
||||
|
||||
gRPC implementations of fail fast can terminate requests whenever a channel is |
||||
in the TRANSIENT_FAILURE or SHUTDOWN states. If the channel is in any other |
||||
state (CONNECTING, READY, or IDLE) the request should not be terminated. |
||||
|
||||
Fail fast SHOULD be the default for gRPC implementations, with an option to |
||||
switch to non fail fast. |
||||
|
||||
The opposite of fail fast is 'ignore connectivity'. |
||||
|
||||
Moved to wait-for-ready.md |
||||
|
@ -0,0 +1,14 @@ |
||||
gRPC Wait for Ready Semantics |
||||
============================= |
||||
|
||||
If an RPC is issued but the channel is in `TRANSIENT_FAILURE` or `SHUTDOWN` |
||||
states, the RPC is unable to be transmited promptly. By default, gRPC |
||||
implementations SHOULD fail such RPCs immediately. This is known as "fail fast," |
||||
but usage of the term is historical. RPCs SHOULD NOT fail as a result of the |
||||
channel being in other states (`CONNECTING`, `READY`, or `IDLE`). |
||||
|
||||
gRPC implementations MAY provide a per-RPC option to not fail RPCs as a result |
||||
of the channel being in `TRANSIENT_FAILURE` state. Instead, the implementation |
||||
queues the RPCs until the channel is `READY`. This is known as "wait for ready." |
||||
The RPCs SHOULD still fail before `READY` if there are unrelated reasons, such |
||||
as the channel is `SHUTDOWN` or the RPC's deadline is reached. |
Loading…
Reference in new issue