huangli
huangli
the develop branch has force-pushed. please rebase this pr. git rebase develop
Flame chart before this commit (only of the ReputMessageService thread):
> I found `System.nanoTime()` was used instead of `System.currentTimeMillis()`, will it bring benefits to performance improvement? It also brings some conversion between nanosecond variables and config values defined in millisecond....
I found the current commit may increase consume lantency in performance test (abount 45ms). I'm working on it.
> Any update? There is no update. But we have run it in out product environment for 3 months.
@dragonTalon Thanks for your contribution. I think this solution introduce too many write.
有很多可能。 拉历史数据对ssd io的占用非常大。 没有"putMessage in lock"不代表没有问题，可能是不够500ms，没有打出日志来，但是积少成多，造成queue堆积的厉害。
upgrade to 4.6.x or upper may resolve your problem. and keep transientStorePoolEnable=false
这个问题我们也遇到，我们的解决办法是给主从同步的tcp连接增加一个握手，我认为这才是根本的解决办法。 不过这样一改就有点不兼容了，比如新旧版本的broker之间无法建立连接，所以这个修改我一直没提交。