我遇到了gRPC C ++客户端针对谷歌云Bigtable进行调用的问题。这些呼叫偶尔会挂起，只有在设置了呼叫截止时间后呼叫才会返回。向gRPC团队提交了一个问题：https://github.com/grpc/grpc/issues/6278带有堆栈跟踪和一段gRPC跟踪日志。
最常挂起的呼叫是ReadRows流读取呼叫。我已经看到MutateRow电话挂了几次，但这种情况很少见。
gRPC跟踪显示有一些响应从服务器返回，但是该响应似乎不足以让gRPC客户端继续。
我确实花了相当多的时间调试代码，到目前为止在客户端找不到明显的问题，没有看到内存损坏。这是一个单线程应用程序，一次调用一次，客户端并发不是一个嫌疑人。客户端在谷歌计算引擎框上运行，因此网络可能也不是问题。 gRPC客户端与github存储库主线保持同步。
任何建议将不胜感激。如果有人有调试的想法也会很棒。使用valgrind，gdb，将应用程序减少到具有可重现结果的子集并没有帮助到目前为止，我还没有找到问题所在。问题是随机的，偶尔出现。
2016年5月17日的附加说明
有人建议重新尝试可能有助于解决这个问题。
不幸的是，重试对我们来说效果不好，因为我们必须将其转移到应用程序逻辑中。我们可以轻松地重新尝试更新，即MutateRow次呼叫，我们这样做，这些不是流式呼叫，很容易重新尝试。但是，一旦应用程序开始迭代DB查询结果，如果它失败，则重新尝试意味着应用程序需要重新发出查询并再次开始迭代结果。这是有问题的。总是可以考虑一个改变，使我们的应用程序一次读取整个结果集，然后在应用程序级别迭代可以在内存中完成。然后可以处理重试。但由于各种原因，例如内存占用和应用程序延迟，这是有问题的。我们希望一旦到达就处理数据库查询结果，而不是在所有数据库都在内存中时。当呼叫挂起时，呼叫延迟也会增加超时。因此，重新尝试查询结果迭代的成本非常高，以至于它们不实用。
答案 0 :(得分：0)
我们遇到过各种语言的gRPC悬而未决的问题。 gRPC团队正在调查。