问题描述
问题原理参考 #3136 , 此问题在 Java-Chassis 1.3 分支上也存在, 我们有业务报告同样的问题现象. 翻阅 Java-Chassis issue 发现此问题在 2.0 分支上已经修复了, 能否在 1.3 分支上也修一下呢?
由于1.3分支的TransportClientConfig是一个静态工具类, 还没办法像 2.0 分支一样使用 SPI 扩展覆盖配置项, 因此只能由 Java-Chassis 框架修复才能解决, 多谢了.
另外, 分析代码来看, Java-Chassis 2.0 分支的代码已经将 HTTP/1.1 和 HTTP/2 的客户端连接池配置区分开了, 但是 Http2TransportHttpClientOptionsSPI 在计算 keepAliveTimeout 时直接继承的 HttpTransportHttpClientOptionsSPI 的逻辑, 导致 HTTP/2 客户端的 keepAlive 超时时间是按照 HTTP/1.1 的 idleTimeout 超时时间减一得到的, 跟 HTTP/2 客户端自身的 idleTimeout 超时时间并无关系, 这里是否应该区分一下, 让 HTTP/1.1 和 HTTP/2 的 keepAlive、idleTimeout 超时时间各自对应才好?
问题描述
问题原理参考 #3136 , 此问题在 Java-Chassis 1.3 分支上也存在, 我们有业务报告同样的问题现象. 翻阅 Java-Chassis issue 发现此问题在 2.0 分支上已经修复了, 能否在 1.3 分支上也修一下呢?
由于1.3分支的
TransportClientConfig是一个静态工具类, 还没办法像 2.0 分支一样使用 SPI 扩展覆盖配置项, 因此只能由 Java-Chassis 框架修复才能解决, 多谢了.另外, 分析代码来看, Java-Chassis 2.0 分支的代码已经将 HTTP/1.1 和 HTTP/2 的客户端连接池配置区分开了, 但是
Http2TransportHttpClientOptionsSPI在计算 keepAliveTimeout 时直接继承的HttpTransportHttpClientOptionsSPI的逻辑, 导致 HTTP/2 客户端的 keepAlive 超时时间是按照 HTTP/1.1 的 idleTimeout 超时时间减一得到的, 跟 HTTP/2 客户端自身的 idleTimeout 超时时间并无关系, 这里是否应该区分一下, 让 HTTP/1.1 和 HTTP/2 的 keepAlive、idleTimeout 超时时间各自对应才好?