In fact，client-pull-for-exception is an alternative way. The push machanism is simple and effective. And, If the nameserver only push the topic names and only one nameserver node will do that, the load is reduced much.
Currently，I believe it is not easy to handle all the exceptions in client for metadata refreshment. For example, if you want to refresh by topic，then you need to handle all the apis which contain topics，it introduces too much code work. If you refresh by all，it will cause too much network load，especially in unstable network environment. List all the exceptions is also not an easy thing. It needs to be designed more carefully. Anyway，performance test is needed. If push-based mechanism invoked too much load，an carefully designed client-pull-for-exception will be considered again. 发自我的 iPhone > 在 2022年3月12日，下午4:17，王金龙 <[email protected]> 写道： > > I think the design is a good point to shorten the unavailable time of > rocketmq when leader change. > > I agree with most of the design point in the doc. > > But the same as others. I think name server push-based topic route will > introduce a lot of load for nameserver. > > How about change to client pull route info when receive exception or receive > leader change-like response code. > > >> On 2022/03/02 11:42:14 xijiu wrote: >> Hi, RocketMQ Community, >> >> As discussed in the previous email, we launched a new RIP to optimize topic >> routing mechanism. Now the shepherds @dongeforever and @yukon are willing to >> support the RIP, so I think it is time to start an email thread to enter the >> voting process. >> >> >> The vote will be open for at least 72 hours or until a necessary number of >> votes are reached. >> >> Please vote accordingly: >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove with the reason >> >> >> Best Regards! >> xijiu >> >> links: >> https://shimo.im/docs/vVAXVrDNnoSrMBqm/
