Hi, jingfeng, I saw beiwei merge your pr, nice work!
However, I think we still need to consider two things. Since we are using a shared timer, this timer will not be closed when a client is closed. In this case, we need to control our tasks without unlimited growth. My current practice is to create a mapping between client and task. When our client is closed, we can find the corresponding task and cancel them. The canceled task will not be re-inserted into the timer. The other thing, I modified the size of the shared timer. In the old version, since each client uses a timer alone, the size of the timer is only 16, and now it is changed to 128 to reduce the hash conflict. My pr is here: https://github.com/apache/incubator-dubbo/pull/3299 Would u pls have a look? 徐靖峰 <[email protected]> 于2019年1月15日周二 下午2:49写道： > Hi folks， > > Here is my suggestion to improve Dubbo’s HeartBeat Design. > > - The design of the two-way heartbeat is unnecessary, compatible with the > existing logic, allowing the client to send a one-way heartbeat when the > connection is idle, and the server periodically detects the connection > availability. Timed time to ensure: client timeout * 3 ≈ server timeout > - Remove the timing tasks for reconnection and disconnection. Dubbo can > judge whether the heartbeat request fails to respond. You can learn from > the design of the improved scheme, maintain a mark of the number of > heartbeat failures at the connection level, and successfully respond to any > failures. Clear the mark; continuous heartbeat failure. The client > initiates a reconnection. This can reduce an unnecessary timer, and any > polling method is not elegant. > > I've described more details in my blog, about Dubbo's existing heartbeat > program, its shortcomings, and the advantages of replacing it with a new > solution, as well as some forward thinking, welcome to discuss. > > bolg：https://www.cnkirito.moe/heartbeat-design/ < > http://www.cnkirito.moe/heartbeat-design/> > > --- > > Hi 乡亲们： > > 我给现有 Dubbo 的心跳方案改进提了两条建议 > > - 双向心跳的设计是不必要的，兼容现有的逻辑，可以让客户端在连接空闲时发送单向心跳，服务端定时检测连接可用性。定时时间尽量保证：客户端超时时间 * > 3 ≈ 服务端超时时间 > - 去除处理重连和断连的定时任务，Dubbo > 可以判断心跳请求是否响应失败，可以借鉴改进方案的设计，在连接级别维护一个心跳失败次数的标记，任意响应成功，清除标记；连续心跳失败 n > 次，客户端发起重连。这样可以减少一个不必要的定时器，任何轮询的方式，都是不优雅的。 > > 我的博客中描述了更多的细节，关于 Dubbo 现有的心跳方案，它的不足之处，以及替换成新的方案的优势，以及一些展望思考，欢迎讨论。 > > 博客地址：https://www.cnkirito.moe/heartbeat-design/
