yuz10
> Is it possible to change the deserialization workflow as follows? > > 1. Attempt to parse the response JSON using standard [go JSON library](http://golang.org/pkg/encoding/json/); > 2. Check and catch...
> @yuz10 @RongtongJin Hi~ I have refactored some code about multi-raft structure! Please check! Thanks~ Hi TheR1sing3un, please fix the merge conflicts.
fixed in #7988
a. 应该需要加个判断，不重复handshake，我找到一段代码https://github.com/doujiang24/lua-resty-kafka/blob/3fbed91d81d4fb32d4dda4316f5f2cba04622633/lib/resty/kafka/broker.lua#L142 b. 连接应该是有nginx管理，不会返回已经关闭的连接 c. 现在确实有点问题，会依赖包的顺序，接受的时候直接把opaque不同的包丢弃了 https://github.com/yuz10/lua-resty-rocketmq/blob/main/lib/resty/rocketmq/core.lua#L550
@humkum can you please fix the failing tests?
Producers are also effective , when creating a ratelimit rule, consume tps and produce tps can be specified seperately
Maybe we can retry SYSTEM_BUSY by default. currently need to call `producer.addRetryResponseCode(ResponseCode.SYSTEM_BUSY); ` to add to retry list
> @yuz10 Is there profiling metrics verifying that prefetch actually improves perf? The performance loss is not related to prefetching. The schedule message deliver speed is 160/s because every time...
@lizhanhui I found no difference between batch and single get key from rocksdb. I will remove prefetch code. Batch: QueryCQ iter 10489877 cost 20527 QueryCQ iter 10489877 cost 19496 QueryCQ...
> 1. The original implementation uses one-shot(at most 16 results) multi-get to simulate iterator; The outcome iterator fails to return all results, thus, does not fit well for the mentioned...