Throws ClientErrorCode.CONNECT_BROKER_EXCEPTION in MQClientException when send max times still failed which in DefaultMQProducerImpl.java

apache / rocketmq

Apache RocketMQ is a cloud native messaging and streaming platform, making it simple to build event-driven applications.

https://rocketmq.apache.org/

Apache License 2.0

21.19k stars 11.67k forks source link

Throws ClientErrorCode.CONNECT_BROKER_EXCEPTION in MQClientException when send max times still failed which in DefaultMQProducerImpl.java #1362

Closed HymanShi closed 2 years ago

HymanShi commented 5 years ago

What did you do?
1. Use rmq clinet to send msg to broker
2. Exception happens when retry to max times and the Exception code makes me confused.
3. I read the rmq client code and find it out
What did you expect to see? Rmq client give me a exception code clearly, eg:RETRY_TO_FAILED
What did you see instead? Throws ClientErrorCode.CONNECT_BROKER_EXCEPTION in MQClientException when send max times still failed which in DefaultMQProducerImpl.java
information: https://github.com/apache/rocketmq/blob/master/client/src/main/java/org/apache/rocketmq/client/impl/producer/DefaultMQProducerImpl.java#L630

And another important issue is : Also in DefaultMQProducerImpl.java#L596 https://github.com/apache/rocketmq/blob/master/client/src/main/java/org/apache/rocketmq/client/impl/producer/DefaultMQProducerImpl.java#L596 Why RemotingSysResponseCode.SYSTEM_BUSY is not in the retry list?Which is set in BrokerFastFailure.java when [TIMEOUT_CLEAN_QUEUE] [PCBUSY_CLEAN_QUEUE] happens

duhenglucky commented 5 years ago

@HymanShi As you described, rocketmq indeed need to polish the mechanism to make it more clear and useful for positioning problem, so would you like to polish this together?

The second question, if the producer still retries when the SYSTEM_BUSY exception was responded by the server, it will increase the load of the server, so in order to protect the server, the producer will stop the retry process.

HymanShi commented 5 years ago

@HymanShi As you described, rocketmq indeed need to polish the mechanism to make it more clear and useful for positioning problem, so would you like to polish this together?

The second question, if the producer still retries when the SYSTEM_BUSY exception was responded by the server, it will increase the load of the server, so in order to protect the server, the producer will stop the retry process.

@duhenglucky Thanks for your invitation, I'd like to polish this mechanism and how can i join it? Reply to the second question:In fact, when users happen the SYSTEM_BUSY or other exceptions which are not in the retry list,users always resend the message themselves immediately in order to prevent sending failure.It will still increase the load of the server.Maybe rocketmq should provide a self-later-resend mechanism when SYSTEM_BUSY or other exception happens.

atris commented 4 years ago

I would like to work on this -- can I be please assigned the same?

duhenglucky commented 4 years ago

@atris thanks for your attention and RocketMQ‘s flow control mechanism can be improved indeed, welcome to participate in the improvement.

duhenglucky commented 4 years ago

@HymanShi Because there are many changes will be involved, so it is necessary to describe the related design and changes in detail, it would be nice if you can submit a RIP in community. I am very glad to help you complete this work.

atris commented 4 years ago

Ah, I did not realise @HymanShi is working on this one, sorry about that!

HymanShi commented 4 years ago

@duhenglucky Thanks for your invitation and I am willing to participate this.I will submit a RIP in community ASAP! @atris Never mind!We can work on this together.

github-actions[bot] commented 2 years ago

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[bot] commented 2 years ago

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