It is ok to add a broker-role-status checking mechanism to avoid ineffective sending.
The push-mechanism only notify the client to refresh metadata. After refreshment by the MQClientInstance，the broker role status could be updated. 发自我的 iPhone > 在 2022年3月12日，下午7:04，WJL3333 <[email protected]> 写道： > > 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/
