chennaji9 opened a new issue, #11293: URL: https://github.com/apache/rocketmq/issues/11293
### Description `docs/en/Operations_Producer.md` contains two factually wrong statements about the producer's behavior on current `develop`. **1. "we will always get SEND_OK if no exception is thrown" is false** The page says (section 1.3, The Log Print): > It is assumed that we will always get SEND_OK if no exception is thrown. `MQClientAPIImpl.processSendResponse` maps broker response codes `FLUSH_DISK_TIMEOUT`, `FLUSH_SLAVE_TIMEOUT` and `SLAVE_NOT_AVAILABLE` to the corresponding `SendStatus` values *without* throwing — only unknown codes raise `MQBrokerException`. So a send that does not throw can legitimately return a non-`SEND_OK` status, which the page itself then goes on to describe in the very list below this sentence. Following the "no exception means SEND_OK" assumption makes applications skip handling of those three statuses (all documented as potential message-loss conditions). **2. Default timeout and async retry count are outdated** Section 2 states: > * The method will retry at most 2 times(2 times in synchronous mode, **0 times in asynchronous mode**). > * ... less then sendMsgTimeout(**default is 10 seconds**). On current `develop`: - `DefaultMQProducer.sendMsgTimeout = 3000` (ms) — not 10 seconds (client/src/main/java/org/apache/rocketmq/client/producer/DefaultMQProducer.java:116); - `DefaultMQProducer.retryTimesWhenSendAsyncFailed = 2` (same file, line 140) — not 0. So both the default timeout and the async retry count in the doc disagree with the code. ### Expected behavior The page should instruct checking `SendResult.getSendStatus()` (not assuming SEND_OK), state the 3000 ms default sendMsgTimeout, and state that async sends also default to 2 retries. -- 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]
