#11293·rocketmq

[Doc] Operations_Producer.md: "no exception means SEND_OK" is wrong and default timeout/retry values are outdated

Author: chennaji9Created Sep 30, 2026Updated Sep 30, 2026

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.