consul/agent/grpc
Daniel Nephin 29e93f6338 grpc: fix a data race by using a static resolver
We have seen test flakes caused by 'concurrent map read and map write', and the race detector
reports the problem as well (prevent us from running some tests with -race).

The root of the problem is the grpc expects resolvers to be registered at init time
before any requests are made, but we were using a separate resolver for each test.

This commit introduces a resolver registry. The registry is registered as the single
resolver for the consul scheme. Each test uses the Authority section of the target
(instead of the scheme) to identify the resolver that should be used for the test.
The scheme is used for lookup, which is why it can no longer be used as the unique
key.

This allows us to use a lock around the map of resolvers, preventing the data race.
2021-06-02 11:35:38 -04:00
..
internal/testservice
resolver grpc: fix a data race by using a static resolver 2021-06-02 11:35:38 -04:00
client.go grpc: fix a data race by using a static resolver 2021-06-02 11:35:38 -04:00
client_test.go grpc: fix a data race by using a static resolver 2021-06-02 11:35:38 -04:00
handler.go Set gRPC keepalives to mirror Yamux keepalive behaviour 2021-04-07 14:09:22 +01:00
server_test.go grpc: fix a data race by using a static resolver 2021-06-02 11:35:38 -04:00
stats.go trim help strings to save a few bytes 2020-11-16 11:02:11 -08:00
stats_test.go grpc: fix grpc metrics 2020-11-11 14:27:25 -05:00