我有一个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。
从我在网上读到的内容来看,人们说不要放弃托管频道,但是流观测者如何,并确保多个流不会被错误地打开?谢谢
当流观察者得到一个错误时,RPC就死了。抛弃它是合适的。
当您重新创建流时,考虑服务器有问题时会发生什么。一般来说,你会在某个地方进行指数退避。对于bidi流媒体案例,如果客户端收到服务器的响应,gRPC中的几个案例倾向于重置回退。
由于两个流一起死了,听起来传输控制协议已经死了。不幸的是,在TCP中,您必须在连接上发送消息才能知道它已经死了。当客户端得知连接已经死了时,它会知道这一点,因为它不能使用该连接发送到HA代理。这意味着HA必须单独发现连接已经死了。服务器端的保持活力可能会有所帮助,尽管HA的TCP保持活力可能也是有保证的。
问题内容: 我有一个RMI服务器和一个桌面RMI客户端。重新启动服务器时,客户端出现错误。是否可以在不重新启动客户端的情况下重新启动RMI连接? [编辑]这是堆栈跟踪: 问题答案: 服务器终止后,您将收到一个ConnectException。之后,您可以使用Naming.lookup获取新的服务器对象。
我使用的代码女巫只允许4个不同端口上的4个连接。此代码正在工作,但当客户端关闭连接时,它无法重新建立连接。连接被拒绝。认为是因为线程关闭。如何解决这个问题?我无法更改端口号... 从套接字导入* BUFF=25 def服务器(主机、端口): 如果名称==“main”:导入线程
将grpc定义的服务视为: 并利用客户端连接到此服务类似于: 如果我们要在一个单独的线程中生成调用,那么处理终止一个永远运行、我们不想再使用的grpc连接的正确方法是什么?是否有任何连接或流控制方法可以调用?
我有一个示例Spring启动应用程序来运行图形QL服务器,具有作为客户端,我的pom有以下依赖项: 当我尝试从客户端连接时,出现以下错误: 狩猎决议好心建议。 我还有几个问题: 我应该使用SimpleGraphQLHttpServlet将请求路由到endpoint吗 我正在React UI上使用apollo client,那么它是强制使用apollo server还是spring boot可以工作
我收到连接重置错误,代码如下。到底是什么原因导致了连接重置?这是因为我试图忽略SSL证书验证的方式吗? 堆栈跟踪 java.net.SocketExcema:连接重置java.net.SocketInputStream.read(SocketInputStream.java:179)com.ibm.jsse2. a. a(a.java:148)com.ibm.jsse2. a. a(a.java: