【发布时间】:2021-01-31 07:39:21
【问题描述】:
grpc 中的 too_many_pings 错误是什么?
-
这些错误是仅从服务器端到客户端还是存在客户端也可以将其发送到服务器端的用例(我知道这很奇怪!但万一存在任何用例!!)
-
出现此错误后,服务器是断开通道还是准备好接收请求?
如何避免?避免它是个好主意吗?
提前致谢, 尼洛特帕
【问题讨论】:
grpc 中的 too_many_pings 错误是什么?
这些错误是仅从服务器端到客户端还是存在客户端也可以将其发送到服务器端的用例(我知道这很奇怪!但万一存在任何用例!!)
出现此错误后,服务器是断开通道还是准备好接收请求?
如何避免?避免它是个好主意吗?
提前致谢, 尼洛特帕
【问题讨论】:
请参阅此https://github.com/grpc/proposal/blob/master/A8-client-side-keepalive.md#server-enforcement 了解更多信息。
是的,仅从服务器到客户端。没有客户端到服务器的用例。
是的,根据https://github.com/grpc/proposal/blob/master/A8-client-side-keepalive.md#server-enforcement。
我认为避免客户端发送过多 ping 是个好主意。在 Java 中,您可以使用 ManagedChannelBuilder.keepAliveTime()。
【讨论】:
这是为了防止 grpc 客户端流即使在流中没有数据移动时也保持连接。 当流处于活动状态且没有数据移动时,客户端会继续 ping 服务器以了解其是否还活着!!从服务器的角度来看,这些连续的 ping 请求基本上是滥用的。当检测到这种陈旧的连接时,服务器会发送此错误并与客户端中断,客户端无法进一步通信或发送任何请求。
但是当客户端想要保持连接数小时,即使没有传入请求时,肯定会出现一些用例。基本上是陈旧的流。
在这些情况下,客户端和服务器都必须自行配置以允许此类 HTTP/2 Ping!!
服务器强制
**Servers will have two settings for enforcement:**
PERMIT_KEEPALIVE_TIME, defaulting to 5 minutes
PERMIT_KEEPALIVE_WITHOUT_CALLS to true
**The client options can be specified** via ManagedChannelBuilder.keepAliveTime(), keepAliveTimeout(), and keepAliveWithoutCalls()
详细文档可以在上面的帖子中找到,@San P 的 github 链接。
【讨论】: