gRPC客户端重新连接逻辑导致服务器端打开重复流

Question

我有一个gRPC客户端，它使用两个bidi流。由于目前未知的原因，当我们每小时发送一次keepAlive ping时，两个流都会调用带有statusRuntimeException的onError。

为了处理重新连接，我在java伪代码中实现了以下重试机制。我将在评论中澄清任何必要的内容。

机制看起来是这样的：

onError() {
    retrySyncStream();
}


void retrySyncStream() {
    // capture the current StreamObserver
    previousStream = this.StreamObserver;

    // open a new stream
    streamObserver = bidiStub.startStream(responseObserver);

    waitForChannelReady(); // <-- simplified version, we use the gRPC notification listener 

    previousStream.onCompleted(); // <-- called on notify of channel READY

}

虽然我们试图关闭旧的流，但在服务器端，我们看到2个HA节点上打开了2个连接。我对服务器端没有任何控制权，我只需要在客户端处理重新连接逻辑。

首先，在获得StatusRuntimeException后抛弃旧的StreamObserver是一种常见做法吗？我之所以这么做，是因为我们有一个模拟服务器spring启动应用程序，用来测试我们的客户机。当我对spring boot server应用程序执行强制关闭（Ctl-c）并再次启动它时，客户端无法使用原始的StreamObserver，它必须通过调用gRPC bidi stream API调用来创建一个新的StreamObserver。

从我在网上读到的内容来看，人们说不要放弃托管频道，但是流观测者如何，并确保多个流不会被错误地打开？谢谢

Answer 1

当流观察者得到一个错误时，RPC就死了。抛弃它是合适的。

当您重新创建流时，考虑服务器有问题时会发生什么。一般来说，你会在某个地方进行指数退避。对于bidi流媒体案例，如果客户端收到服务器的响应，gRPC中的几个案例倾向于重置回退。

由于两个流一起死了，听起来传输控制协议已经死了。不幸的是，在TCP中，您必须在连接上发送消息才能知道它已经死了。当客户端得知连接已经死了时，它会知道这一点，因为它不能使用该连接发送到HA代理。这意味着HA必须单独发现连接已经死了。服务器端的保持活力可能会有所帮助，尽管HA的TCP保持活力可能也是有保证的。