gRPC wait server ready

490 views
Skip to first unread message

Сергей Соболев

unread,
Nov 9, 2021, 4:06:03 PM11/9/21
to grpc.io
Hi, everyone!
I'm writing test (with gtest) with grpc similar to the following (in C++ pseudocode):

class Fixture {
  void SetUp() { m_server = BuildAndStart(); }
  void TearDown() { m_server->Shutdown(); }
};

TEST_F(Fixture, Test1) { ASSERT_EQ(clientStub->rpcCall(ctx), grpc::Status::OK); }
TEST_F(Fixture, Test2) { ASSERT_EQ(clientStub->rpcCall(ctx), grpc::Status::OK); }

When compiling (clang++11) with a thread sanitizer (grpc library compiling with tsan too) sometimes I get an error UNAVALABLE (code 14) with logs:
"Failed to pick subchannel", "Failed to connect to all addresses" and observe the state of the channel is TRANSIENT_FAILURE.
But only the first test always fails (Test1). Searching the internet I found the following suitable solution https://chromium.googlesource.com/external/github.com/grpc/grpc/+/HEAD/examples/python/wait_for_ready/
In other words, with tsan I guess grpc library does not have enough time to fully initialize (Test2 is always OK). After use grpc::ClientContext::set_wait_for_ready(bool) method problem solved

TEST_F(Fixture, Test1) { ASSERT_EQ(clientStub->rpcCall(ctxWithWait), grpc::Status::OK); }
TEST_F(Fixture, Test2) { ASSERT_EQ(clientStub->rpcCall(ctxWithWait), grpc::Status::OK); }

My questions are:
  1. grpc::ClientContext::set_wait_for_ready(bool) marked as EXPERIMENTAL (C++ api) and may be removed in the future, but grpc::ClientContext::set_fail_fast(bool) method is DEPRECATED. It's recommended to use wait_for_ready(). Is it true that in the future set_wait_for_ready should become a replacement set_fail_fast?
  2. Are there any other ways to solve this problem? I was also looking at ChannelState API https://chromium.googlesource.com/external/github.com/grpc/grpc/+/refs/heads/chromium-deps/2016-09-09/doc/connectivity-semantics-and-api.md Which way is more correct and reliable?
I will also need to implement similar logic in C# code. In C# this is a CallOptions.WithWaitForReady(bool) method, but it's EXPERIMENTAL too

Wished to clear up a misunderstanding and choose the right solution.

Thank you for your time.
Highly appreciated.
Sergey

yas...@google.com

unread,
Dec 1, 2021, 1:27:36 PM12/1/21
to grpc.io
I think this API is pretty stable and should be promoted. https://github.com/grpc/grpc/pull/28247

Сергей Соболев

unread,
Dec 2, 2021, 5:41:33 AM12/2/21
to grpc.io
Good news, thank you!

среда, 1 декабря 2021 г. в 21:27:36 UTC+3, yas...@google.com:
Reply all
Reply to author
Forward
0 new messages