wz2cool commented on PR #5845: URL: https://github.com/apache/rocketmq/pull/5845#issuecomment-1408038481
> > > > @cserwen > > > > we have lot of disussion about it, plz see #2726 , I think you can add SYSTEM_BUSY using addRetryResponseCode method by yourself . you can see my changes #2729 > > > >  > > > > > > > > > @wz2cool The sdk's built-in retry is necessary. System busy is a very common situation. If this situation needs to be specified by the user, then our sdk seems difficult to use. In addition, we can easily implement it, why require users to add code by themselves > > > > > > some rocketmq designers/members/contributors worried about overload, so sdk's build-in retry PR can't be merged long time ago. I think it's ok to use sdk's built in retry if there is no any risk to do this. > > Actually，sdk will also retry when broker returns SYSTEM_ERROR. And when the pagecache is busy, the response code is SYSTEM_ERROR. In our internal, RocketMQ has been running for more than two years, and the entire cluster has not been overloaded because of a single Broker's busy, so this worry is unnecessary. Besides, the commercial version also supports retrying in this case, why can't the open-source version support it? In some cases, users don't run multi rocketmqs as cluster , they just run one rocketmq/nameserver (considering the cost) , I think commercial version is also a cluster. I support to use build-in retrying if no risk in any case. Could someone make some tests to prove it. Currently, I think config is a good choose. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
