Chiebot-Mirror
/
grpc
mirror of https://github.com/grpc/grpc.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#) https://grpc.io/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
55418 Commits
280 Branches
379 Tags
1.3 GiB
 
 
 
 
 
 
Tag: Branch: Tree: a3ab7c73aa
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'a3ab7c73aa'
${ noResults }
grpc/examples/python/wait_for_ready
Michael c4bbaa25f8
Fix Typos In Docs & Code Comments (#37170) 		5 months ago
..
test [Python] Migrate from yapf to black (#33138) 2 years ago
BUILD.bazel Make Buildifier Sanity Test Strict (#27807) 3 years ago
README.md Adopt reviewer's advice 6 years ago
asyncio_wait_for_ready_example.py [Python] Migrate from yapf to black (#33138) 2 years ago
helloworld.proto Adding three more AsyncIO examples 4 years ago
wait_for_ready_example.py [Python] Migrate from yapf to black (#33138) 2 years ago
wait_for_ready_with_client_timeout_example_client.py [Python] Migrate from yapf to black (#33138) 2 years ago
wait_for_ready_with_client_timeout_example_server.py Fix Typos In Docs & Code Comments (#37170) 5 months ago

README.md

gRPC Python Example for Wait-for-ready

The default behavior of an RPC is to fail instantly if the server is not ready yet. This example demonstrates how to change that behavior.

Definition of '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 transmitted promptly. By default, gRPC implementations SHOULD fail such RPCs immediately. This is known as "fail fast," but the 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.

From https://github.com/grpc/grpc/blob/master/doc/wait-for-ready.md

Use cases for 'wait-for-ready'

When developers spin up gRPC clients and servers at the same time, it is very like to fail first couple RPC calls due to unavailability of the server. If developers failed to prepare for this situation, the result can be catastrophic. But with 'wait-for-ready' semantics, developers can initialize the client and server in any order, especially useful in testing.

Also, developers may ensure the server is up before starting client. But in some cases like transient network failure may result in a temporary unavailability of the server. With 'wait-for-ready' semantics, those RPC calls will automatically wait until the server is ready to accept incoming requests.

DEMO Snippets

# Per RPC level
stub = ...Stub(...)

stub.important_transaction_1(..., wait_for_ready=True)
stub.unimportant_transaction_2(...)
stub.important_transaction_3(..., wait_for_ready=True)
stub.unimportant_transaction_4(...)
# The unimportant transactions can be status report, or health check, etc.