Cc

It will cause the client to fail when the master goes down.is this reasonable？I always thought the client was insensitive

When I set the timeout to 10s, it still cannot be retried correctly. 2022-08-02 16:22:05,917 WARN RocketmqClient - sendKernelImpl exception, resend at once, InvokeID: -2111425297163537192, RT: 10015ms, Broker: MessageQueue [topic=CONNECT,...

> #3555 @Cczzzz Verify that this PR solves this issue @duhenglucky no,is different

> 有很多可能。 > > 拉历史数据对ssd io的占用非常大。 > > 没有"putMessage in lock"不代表没有问题，可能是不够500ms，没有打出日志来，但是积少成多，造成queue堆积的厉害。 拉取历史消息触发缺页时是否会堵塞写入呢，linux 下有log记录这种情况吗，这个问题我查好几天了。 除了这个情况，还有可能是dledger 存储库的问题吗，4.7用的是0.1 而最新版是0.22

> 请运行`./gradlew spotlessApply`并提交生成的更改。 > 也请重命名`GrpcMetadataConfiguration`为`GrpcCloudMetadataConfiguration`. ok

我在ack 确认的任务中增加了许多log来确定耗时的问题，如下 @Override public void doWork() { long start = System.nanoTime(); try { if (DLedgerUtils.elapsed(lastPrintWatermarkTimeMs) > 3000) { logger.info("[{}][{}] term={} ledgerBegin={} ledgerEnd={} committed={} watermarks={}", memberState.getSelfId(), memberState.getRole(), memberState.currTerm(), dLedgerStore.getLedgerBeginIndex(), dLedgerStore.getLedgerEndIndex(), dLedgerStore.getCommittedIndex(),...

pending size 206 is map size before loop .< 1000.Maybe it's caused by read-write locks and hash collisions. map 里面所有的key都是递增的数字，hash 冲突是否是会很严重呢，如果hash 冲突加上读写锁可能是引起耗时高的关键

maxPendingRequestsNum is default 10000.

 主从同步也是严重影响性能的问题，太多在这里要耗费10ms的情况了，我还没有看slave接受请求的逻辑

同步给slave 要先将消息从pagche里面读出来，然后解码，然后再json 编码，然后才是发送，是否用bp来代替json更好呢  这部分json是否应该放在多线程里面