xds: refactor server-side HTTP filter processing (#8878) While working on xDS HTTP filter state retention changes required for A83 and A86 in https://github.com/grpc/grpc-go/pull/8745, I realized that the current implementation of HTTP filters on the server-side does not lend itself well to the changes we want to make to support filter state retention. The crux of the problem in the current implementation is as follows: - The `xdsresource` package builds a `FilterChainManager` type that does the following: - Keeps track of the list of Route Configuration resources to be requested based on the HTTP filters configured on the Listener resource - Updates the interceptors on the different filter chains based on Route Configuration resource updates (that contain filter config overrides) - Maintaining runtime state in a type that is supposed to represent a configuration blob seems to have been a wrong implementation choice - Everytime a Listener resource update is received, the `xdsresource` package builds a brand new `FilterChainManager` - This means that we *cannot* retain filter state across resource updates This PR makes the following changes: - Changes the layout of the `ListenerUpdate` struct to clearly separate client-side and server-side fields - Also groups information that is shared across client and server listener types into a logical struct - The `ListenerUpdate` will *only* contain information directly sourced from the listener proto - The xDS server implementation will build the runtime representation of the filter chains using the configuration update provided by the `xdsresource` package - This would move the responsibility of updating the interceptors on the filter chain to the xDS server, which is the correct place to be doing such a thing - This would make it possible for the xDS server implementation to retain filter state across listener resource updates RELEASE NOTES: none
The Go implementation of gRPC: A high performance, open source, general RPC framework that puts mobile and HTTP/2 first. For more information see the Go gRPC docs, or jump directly into the quick start.
Simply add the following import to your code, and then go [build|run|test] will automatically fetch the necessary dependencies:
import "google.golang.org/grpc"
Note: If you are trying to access
grpc-gofrom China, see the FAQ below.
The golang.org domain may be blocked from some countries. go get usually produces an error like the following when this happens:
$ go get -u google.golang.org/grpc package google.golang.org/grpc: unrecognized import path "google.golang.org/grpc" (https fetch: Get https://google.golang.org/grpc?go-get=1: dial tcp 216.239.37.1:443: i/o timeout)
To build Go code, there are several options:
Set up a VPN and access google.golang.org through that.
With Go module support: it is possible to use the replace feature of go mod to create aliases for golang.org packages. In your project's directory:
go mod edit -replace=google.golang.org/grpc=github.com/grpc/grpc-go@latest go mod tidy go mod vendor go build -mod=vendor
Again, this will need to be done for all transitive dependencies hosted on golang.org as well. For details, refer to golang/go issue #28652.
Please update to the latest version of gRPC-Go using go get google.golang.org/grpc.
The default logger is controlled by environment variables. Turn everything on like this:
$ export GRPC_GO_LOG_VERBOSITY_LEVEL=99 $ export GRPC_GO_LOG_SEVERITY_LEVEL=info
"code = Unavailable desc = transport is closing"This error means the connection the RPC is using was closed, and there are many possible reasons, including:
It can be tricky to debug this because the error happens on the client side but the root cause of the connection being closed is on the server side. Turn on logging on both client and server, and see if there are any transport errors.