mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
e637661ea2
* Adding a way to inject a request ID It is very useful to associate a request ID to each incoming request, this change allows to provide a function to do that via Server Option. The change comes with a default function which will generate a new request ID. The request ID is put in the request context along with a common logger which always logs the request-id We add gRPC interceptors to the server so it can get the request ID out of the gRPC metadata and put it in the common logger stored in the context so as all the log lines using the common logger from the context will have the request ID logged
26 lines
940 B
Go
26 lines
940 B
Go
// Copyright 2016 Michal Witkowski. All Rights Reserved.
|
|
// See LICENSE for licensing terms.
|
|
|
|
/*
|
|
`grpc_retry` provides client-side request retry logic for gRPC.
|
|
|
|
Client-Side Request Retry Interceptor
|
|
|
|
It allows for automatic retry, inside the generated gRPC code of requests based on the gRPC status
|
|
of the reply. It supports unary (1:1), and server stream (1:n) requests.
|
|
|
|
By default the interceptors *are disabled*, preventing accidental use of retries. You can easily
|
|
override the number of retries (setting them to more than 0) with a `grpc.ClientOption`, e.g.:
|
|
|
|
myclient.Ping(ctx, goodPing, grpc_retry.WithMax(5))
|
|
|
|
Other default options are: retry on `ResourceExhausted` and `Unavailable` gRPC codes, use a 50ms
|
|
linear backoff with 10% jitter.
|
|
|
|
For chained interceptors, the retry interceptor will call every interceptor that follows it
|
|
whenever when a retry happens.
|
|
|
|
Please see examples for more advanced use.
|
|
*/
|
|
package grpc_retry
|