Yes, I agree with you, both approach do the same thing. If we design in a pull-for-exception way. more work should be done.
I think the dledger-based rocketmq can introduce more broker status about current broker role which can be a good indicator for client to refresh metadata. if producer receive not-leader response code, refresh metadata is needed. It should not send the message to the broker until the metadata refresh. Nameserver-pushed way is async to the producer send code path. I think this can be avoided. On 2022/03/12 09:37:45 刘振东 wrote: > 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/ >
