You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
configuration details are outlined in the [proposal](https://github.com/grpc/proposal/blob/master/A6-client-retries.md).
100
-
101
-
This retrying example is very similar to the [hedging example](src/main/java/io/grpc/examples/hedging) in its setup.
102
-
The [RetryingHelloWorldServer](src/main/java/io/grpc/examples/retrying/RetryingHelloWorldServer.java) responds with
103
-
a status UNAVAILABLE error response to a specified percentage of requests to simulate server resource exhaustion and
104
-
general flakiness. The [RetryingHelloWorldClient](src/main/java/io/grpc/examples/retrying/RetryingHelloWorldClient.java) makes
105
-
a number of sequential requests to the server, several of which will be retried depending on the configured policy in
106
-
[retrying_service_config.json](src/main/resources/io/grpc/examples/retrying/retrying_service_config.json). Although
107
-
the requests are blocking unary calls for simplicity, these could easily be changed to future unary calls in order to
108
-
test the result of request concurrency with retry policy enabled.
109
-
110
-
One can experiment with the [RetryingHelloWorldServer](src/main/java/io/grpc/examples/retrying/RetryingHelloWorldServer.java)
111
-
failure conditions to simulate server throttling, as well as alter policy values in the [retrying_service_config.json](
112
-
src/main/resources/io/grpc/examples/retrying/retrying_service_config.json) to see their effects. To disable retrying
113
-
entirely, set environment variable `DISABLE_RETRYING_IN_RETRYING_EXAMPLE=true` before running the client.
114
-
Disabling the retry policy should produce many more failed gRPC calls as seen in the output log.
115
-
116
-
See [the section below](#to-build-the-examples) for how to build and run the example. The
117
-
executables for the server and the client are `retrying-hello-world-server` and
118
-
`retrying-hello-world-client`.
119
-
120
-
</details>
121
-
122
-
- <details>
123
-
<summary>Health Service</summary>
124
-
125
-
The [health service example](src/main/java/io/grpc/examples/healthservice)
126
-
provides a HelloWorld gRPC server that doesn't like short names along with a
127
-
health service. It also provides a client application which makes HelloWorld
128
-
calls and checks the health status.
129
-
130
-
The client application also shows how the round robin load balancer can
131
-
utilize the health status to avoid making calls to a service that is
### <aname="to-build-the-examples"></a> To build the examples
139
57
140
58
1.**[Install gRPC Java library SNAPSHOT locally, including code generation plugin](../COMPILING.md) (Only need this step for non-released versions, e.g. master HEAD).**
When a gRPC client is no longer interested in the result of an RPC call,
5
+
it may cancel to signal this discontinuation of interest to the server.
6
+
7
+
Any abort of an ongoing RPC is considered "cancellation" of that RPC.
8
+
The common causes of cancellation are the client explicitly cancelling, the deadline expires, and I/O failures.
9
+
The service is not informed the reason for the cancellation.
10
+
11
+
There are two APIs for services to be notified of RPC cancellation: io.grpc.Context and ServerCallStreamObserver
12
+
13
+
Context listeners are called on a different thread, so need to be thread-safe.
14
+
The ServerCallStreamObserver cancellation callback is called like other StreamObserver callbacks,
15
+
so the application may not need thread-safe handling.
16
+
Both APIs have thread-safe isCancelled() polling methods.
17
+
18
+
Refer the gRPC documentation for details on Cancellation of RPCs https://grpc.io/docs/guides/cancellation/
One of the key features of gRPC is load balancing, which allows requests from clients to be distributed across multiple servers.
5
+
This helps prevent any one server from becoming overloaded and allows the system to scale up by adding more servers.
6
+
7
+
A gRPC load balancing policy is given a list of server IP addresses by the name resolver.
8
+
The policy is responsible for maintaining connections (subchannels) to the servers and picking a connection to use when an RPC is sent.
9
+
10
+
This example gives the details about how we can implement our own custom load balance policy, If the built-in policies does not meet your requirements
11
+
and follow below steps for the same.
12
+
13
+
- Register your implementation in the load balancer registry so that it can be referred to from the service config
14
+
- Parse the JSON configuration object of your implementation. This allows your load balancer to be configured in the service config with any arbitrary JSON you choose to support
15
+
- Manage what backends to maintain a connection with
16
+
- Implement a picker that will choose which backend to connect to when an RPC is made. Note that this needs to be a fast operation as it is on the RPC call path
17
+
- To enable your load balancer, configure it in your service config
18
+
19
+
Refer the gRPC documentation for more details https://grpc.io/docs/guides/custom-load-balancing/
A Deadline is used to specify a point in time past which a client is unwilling to wait for a response from a server.
5
+
This simple idea is very important in building robust distributed systems.
6
+
Clients that do not wait around unnecessarily and servers that know when to give up processing requests will improve the resource utilization and latency of your system.
7
+
8
+
Note that while some language APIs have the concept of a deadline, others use the idea of a timeout.
9
+
When an API asks for a deadline, you provide a point in time which the call should not go past.
10
+
A timeout is the max duration of time that the call can take.
11
+
A timeout can be converted to a deadline by adding the timeout to the current time when the application starts a call.
12
+
13
+
This Example gives usage and implementation of Deadline on Server, Client and Propagation.
14
+
15
+
Refer the gRPC documentation for more details on Deadlines https://grpc.io/docs/guides/deadlines/
If a gRPC call completes successfully the server returns an OK status to the client (depending on the language the OK status may or may not be directly used in your code).
5
+
But what happens if the call isn’t successful?
6
+
7
+
This Example gives the usage and implementation of how return the error details if gRPC call not successful or fails
8
+
and how to set and read com.google.rpc.Status objects as google.rpc.Status error details.
9
+
10
+
gRPC allows detailed error information to be encapsulated in protobuf messages, which are sent alongside the status codes.
11
+
12
+
If an error occurs, gRPC returns one of its error status codes with error message that provides further error details about what happened.
13
+
14
+
Refer the below links for more details on error details and status codes
Error handling in gRPC is a critical aspect of designing reliable and robust distributed systems.
5
+
gRPC provides a standardized mechanism for handling errors using status codes, error details, and optional metadata.
6
+
7
+
This Example gives the usage and implementation of how to handle the Errors/Exceptions in gRPC,
8
+
shows how to extract error information from a failed RPC and setting and reading RPC error details.
9
+
10
+
If a gRPC call completes successfully the server returns an OK status to the client (depending on the language the OK status may or may not be directly used in your code).
11
+
12
+
If an error occurs gRPC returns one of its error status codes with error message that provides further error details about what happened.
13
+
14
+
Error Propagation:
15
+
- When an error occurs on the server, gRPC stops processing the RPC and sends the error (status code, description, and optional details) to the client.
16
+
- On the client side, the error can be handled based on the status code.
17
+
18
+
Client Side Error Handling:
19
+
- The gRPC client typically throws an exception or returns an error object when an RPC fails.
20
+
21
+
Server Side Error Handling:
22
+
- Servers use the gRPC API to return errors explicitly using the grpc library's status functions.
23
+
24
+
gRPC uses predefined status codes to represent the outcome of an RPC call. These status codes are part of the Status object that is sent from the server to the client.
25
+
Each status code is accompanied by a human-readable description(Please refer https://github.com/grpc/grpc-java/blob/master/api/src/main/java/io/grpc/Status.java)
26
+
27
+
Refer the gRPC documentation for more details on Error Handling https://grpc.io/docs/guides/error/
This example shows how clients can specify compression options when performing RPCs,
5
+
and how to enable compressed(i,e gzip) requests/responses for only particular method and in case of all methods by using the interceptors.
6
+
7
+
Compression is used to reduce the amount of bandwidth used when communicating between client/server or peers and
8
+
can be enabled or disabled based on call or message level for all languages.
9
+
10
+
gRPC allows asymmetrically compressed communication, whereby a response may be compressed differently with the request,
11
+
or not compressed at all.
12
+
13
+
Refer the gRPC documentation for more details on Compression https://grpc.io/docs/guides/compression/
0 commit comments