Jayant
Jayant
尴尬，我刚提了个commit，加了h2的idle timer。。 https://github.com/mosn/mosn/pull/1902/files
> > > > 这样实现只是满足h2的，我想的是作用到最底层的conn上，跟downtream的idletimeout一样 有些协议是自带keepalive的，像gRPC，始终会有包在发，作用在底层conn上的要怎么关闭连接呢？
> > > > > > > > > > > > > > 这样实现只是满足h2的，我想的是作用到最底层的conn上，跟downtream的idletimeout一样 > > > > > > 有些协议是自带keepalive的，像gRPC，始终会有包在发，作用在底层conn上的要怎么关闭连接呢？ > > gRPC 没有始终发包吧？ 有的吧，官方库起了个goroutine持续发ping包。 我理解idle的含义是这个连接没有任何请求了，而不是没有数据包。如果设置idle = 5s，假设请求响应时间超过5s连接断了，就麻烦了
> > 我在grpc的标准里没有看到这种呢？你说的是go grpc client的默认实现？ https://github.com/grpc/grpc-go/blob/fbaf7c55821070944bb0ce342ba3c54cc521c6fe/internal/transport/http2_client.go#L1561 是的，go client默认实现了
我看现在network层已经实现了连接的idle time，而且默认是90s. 现在缺的应该是h1 h2本身可以配置的idle time.
> 是的哈，目前downstream的conn可以配置，upstream的都不可配置，目前我们h2的upstream也是没有心跳包的，用这个方案应该就行了 那你看[PR](https://github.com/mosn/mosn/pull/1902/files)里的idle timer还合入吗？不合的话我reset掉吧
> 好的哈，idle的可以reset，然后直接ongoaway看起就可以了，后面加上这个conn的idle timeout配置 Done.
不过感觉90s还是太激进了吧。。是不是再设长点好些？
> > #1671 之前有个类似的issue > > > > 1. 重试开关和规则可以支持变量，这样用户可以用filter来动态控制一些较复杂的重试条件。 > > 2. 错误码的重试需要可配置，目前配死了大于500 > > OK 老哥，这个issue现在啥进度了？
补充性能压测结果： **Buffered：** commit | TPS | TP99 | TP999 | Server CPU AVG| Client CPU AVG -- | -- | -- | -- | -- | -- 9d86568 | 206608...