Yuhang, Nice catch. Could you pls. review my comments on your pull request?
Thanks, -Ian. On Tue, Jan 22, 2019 at 11:36 AM yuhang xiu <[email protected]> wrote: > 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/ >
