问题原理
如果业务没有配置Keep-alive超时时间, 则Java-Chassis会取客户端idle超时时间, idle超时>1秒就取 Keep-alive超时时间=(idle超时 - 1秒). 这个计算逻辑在TransportClientConfig中.
但由于Vert.x检查HTTP长连接是否需要做Keep-alive超时断连处理的定时任务, 其默认的执行时间间隔是1秒钟(参考 io.vertx.core.http.impl.HttpClientImpl#checkExpired 方法, 入参的options.getPoolCleanerPeriod()的默认值为io.vertx.core.http.HttpClientOptions#DEFAULT_POOL_CLEANER_PERIOD, 刚好1秒). 这个1秒钟的时间间隔跟 Keep-alive 和 idle超时的间隔相同, 所以有可能Keep-alive超时机制可能由于误差, 落到idle超时的后面, idle超时先触发, 业务请求发送时就会碰到连接断开问题.
我们是在HTTP/2长连接场景下遇到的这个问题, 触发概率非常小. 经过检查代码, 发现Java-Chassis 1.x 和 2.x 分支都存在这种问题.
能否优化一下Keep-alive的默认值计算逻辑, 避免这种问题?
问题原理
如果业务没有配置Keep-alive超时时间, 则Java-Chassis会取客户端idle超时时间, idle超时>1秒就取 Keep-alive超时时间=(idle超时 - 1秒). 这个计算逻辑在
TransportClientConfig中.但由于Vert.x检查HTTP长连接是否需要做Keep-alive超时断连处理的定时任务, 其默认的执行时间间隔是1秒钟(参考
io.vertx.core.http.impl.HttpClientImpl#checkExpired方法, 入参的options.getPoolCleanerPeriod()的默认值为io.vertx.core.http.HttpClientOptions#DEFAULT_POOL_CLEANER_PERIOD, 刚好1秒). 这个1秒钟的时间间隔跟 Keep-alive 和 idle超时的间隔相同, 所以有可能Keep-alive超时机制可能由于误差, 落到idle超时的后面, idle超时先触发, 业务请求发送时就会碰到连接断开问题.我们是在HTTP/2长连接场景下遇到的这个问题, 触发概率非常小. 经过检查代码, 发现Java-Chassis 1.x 和 2.x 分支都存在这种问题.
能否优化一下Keep-alive的默认值计算逻辑, 避免这种问题?