Client will not retry to send message when broker busy

[cserwen]

BUG REPORT

1. Please describe the issue you observed:

Client will retry when server returns the following code:

But some code of broker-busy is SYSTEM_BUSY, the client will stop to retry. Broker's glitch will cause the client to stop retrying, resulting in sending failure. If it can retry to other Broker nodes, this problem can be avoided.

2. Please tell us about your environment:

3. Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):

[fuyou001]

In most case, when broker return SYSTEM_BUSY error code ,means brokers can't process more request,so sdk can't retry.
if send order message,the more complex, sdk can't simple retry

[cserwen]

IMO，SYSTEM_BUSY only meas current broker can't process so many requests, but other broker is ok. If it will retry in this case, the client will not fail to send and users will not see this error. @fuyou001

[cserwen]

As for order messages, the retry logic of SDK has already considered this scenario, so there is no need to worry about it.

[francisoliverlee]

IMO，SYSTEM_BUSY only meas current broker can't process so many requests, but other broker is ok. If it will retry in this case, the client will not fail to send and users will not see this error. @fuyou001

顺序消息目前是分区顺序，也就是在相同queue里面的消息可以保证顺序。当重试到其他broker的时候，queue变化了，如何保证消息的顺序性就是一个问题。目前sdk里面是如何处理这种场景的呢， 我没有找到相关的code， 老哥可以发一下哇？

[cserwen]

顺序消息根本就不会重试呀，和普通发送使用的方法不一样，顺序消息调用sendSelectImpl，这里面没有重试逻辑，我这里说的只是针对普通消息的发送重试，包含重试逻辑的代码处于sendDefaultImpl方法。 @francisoliverlee

[ShadowySpirits]

In most case, when broker return SYSTEM_BUSY error code ,means brokers can't process more request,so sdk can't retry. if send order message,the more complex, sdk can't simple retry

It is unlikely that all brokers are busy, so retrying to other nodes makes sense. Besides, retrying on TOPIC_NOT_EXIST seems meaningless.

[ni-ze]

IMO, It is ok to retry when the error code is SYSTEM_BUSY, the commercial version does retry when the return is SYSTEM_BUSY.

[github-actions]

This issue is stale because it has been open for 365 days with no activity. It will be closed in 3 days if no further activity occurs.

[github-actions]

This issue was closed because it has been inactive for 3 days since being marked as stale.