fibbery

will release in next version ? Erik Dubbelboer ***@***.***> 于2023年11月10日周五 18:32写道： > We already have an exposed function with the same name. I would be open to > a pull...

Ok, I'll do that. Erik Dubbelboer ***@***.***>于2023年11月10日 周五19:02写道： > I mean, if you create a pull request for the feature, then I can merge it > and release it in...

我的场景是 -> mosn -> （HTTP）各类业务 server 业务 server 是有一个空闲检测的逻辑（5s 未读未写），因为我们遇到了这种情况： 1. mosn 转发请求过去 server 2. server 空闲检测刚好到时间，直接就关闭连接了 我们想在 mosn 这一层通过增加一个空闲检测的手段避免出现这种情况。这里我想通过判断当前连接是否又发送请求的状态，如果有的，就不认为是空闲状态，避免这种情况。不知道是否合理

我怎么感觉这个 idlechecker 不管是 ping-pong 还是 multi ，都没考虑这种情况，都有可能误杀。 这个状态我感觉还是得放在连接上，让连接去触发读超时得时候，不回调这个 idlechecker，这个是不是比较合理点

我还有一个想法，就是在 idlechecker 里面增加两个参数，lastWriteTime 和 lastReadTime，如果 lastWriteTime 较新，证明这个连接发送请求还没回应，可以忽略空闲检测，反之则进行正常的空闲检测。这种至少能排除掉在等待响应的这种情况

> 我理解是无解的，没办法避免这个问题。 为啥，我这么处理不行么

> 你server有空闲检查，肯定是有几率会碰撞到，导致请求失败的 我只要比 server 的空闲检测小，就不太可能吧，假设 server 都是统一设置的空闲检测时间

> > > 你server有空闲检查，肯定是有几率会碰撞到，导致请求失败的 > > > > > > 我只要比 server 的空闲检测小，就不太可能吧，假设 server 都是统一设置的空闲检测时间 > > 你们可以不要使用 mosn 里面默认实现的 idleChecker，可以自己在 streamfilter 中实现一个带业务语义的 idleChcker, 然后自己去主动关闭 tcp 连接 streamfilter 不能处理吧，我理解 networkfilter...

我觉得你可以用supplyAsync(Supplier supplier,Executor executor)这个解决，自定义一个Executor来处理。 要么就是监听SpringApplicationEvent的各种事件，在监听处代码把ForkJoinPool.common.threadFactory这个final属性修改成自己的MyFactory

我理解应该是类似这样： ```golang if kp.idleFree.CheckFree(id) { // determine if only the hb request pending for sending if kp.Codec.ActiveRequestsNum() == 1 { kp.Codec.Close() return } else { // reset idleCount atomic.StoreUint32(&kp.idleFree.idleCount, 0)...