Good news, thank you! среда, 1 декабря 2021 г. в 21:27:36 UTC+3, [email protected]:
> I think this API is pretty stable and should be promoted. > https://github.com/grpc/grpc/pull/28247 > > On Tuesday, November 9, 2021 at 1:06:03 PM UTC-8 Сергей Соболев wrote: > >> 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(ctx*WithWait*), >> grpc::Status::OK); } >> TEST_F(Fixture, Test2) { ASSERT_EQ(clientStub->rpcCall(ctx*WithWait*), >> 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 >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/1ae8c323-1e96-457f-8a89-e1d9a42d9fe2n%40googlegroups.com.
