Yesterday I received a reply from the netty community: just because we usually want to be on the same thread as the EventLoop of > the Channel. that said there is nothing wrong about the HashedWheelTimer.
It seems that netty does not use HashedWheelTimer not because of its own problems. I think we can safely continue to use HashedWheelTimer. However, we still need to pay attention to the fact that if there is a large delay in the task, we need to use or even give up using HashedWheelTimer, and the task that seems to be blocked is not suitable. Thx for jingfeng's question. Very valuable. :) Jason Joo <[email protected]> 于2019年1月24日周四 上午10:44写道： > hi, moe > > This is the main differences: > > ScheduledThreadPoolExecutor > > O(log N) for adding new task > O(1) per each timer tick (but tick per each task, so N overall) > O(log N) cancelling the task > lock per each tick/task > HashedWheelTimer > > O(1) adding new task > O(m) per each timer tick (m ~ N/C where C > 512 approx), so ~C ticks > overall > O(m) for cancelling a task > lock per bucket of tasks (on each tick) > > > best regards, > > Jason > > > On Jan 24, 2019, at 10:09, 徐靖峰 <[email protected]> wrote: > > > > Hi, Jason，a nice opinion. > > > > I have noticed that this issue[1] in Github encourage the change from > Schedule to HashedWheelTimer, but didn’t give a vert detailed reason. > > > > Is HashedWheelTimer really an unquestionable choice? > > > > [1] https://github.com/apache/incubator-dubbo/issues/1371 < > https://github.com/apache/incubator-dubbo/issues/1371> > > > >> 在 2019年1月24日，上午9:53，Jason Joo <[email protected]> 写道： > >> > >> Maybe because the main scenario dubbo faces is persistent connection. > >> For persistent connections the most frequent thing is ticking. > >> > >> ScheduledThreadPoolExecutor is O(1)*connections compared to O(C) in > HashedWheelTimer when ticking. > >> Considering connections is far less then C ScheduledThreadPoolExecutor > maybe more efficient in my opinion. > >> > >> best regards, > >> > >> Jason > > > >
