version

4.7.1. The following instructions refer to this version

features

Website shows

The send method of Producer supports internal retry. The retry logic is as follows:

  • Retry at most two times.
  • If synchronous mode fails to send, it is forwarded to the next Broker, and if asynchronous mode fails, only the current Broker is retried. The total time for this method does not exceed the value set by sendMsgTimeout, which defaults to 10 seconds.
  • If sending a message to the broker itself causes a timeout exception, it will not retry.

The above policies also ensure that messages can be sent successfully to a certain extent. If services have high requirements on message reliability, you are advised to add retry logic. For example, if the send synchronization method fails to be invoked, the system tries to store the message to the DB, and the background thread periodically tries again to ensure that the message reaches the Broker.

Pay attention to

  • If an exception occurs during the asynchronous transmission, the request is parsed. If the response status code is abnormal (the message may be incorrectly processed by the broker), the request is parsed again and the current Broker is still selected. However, if the response result is not empty, the retry will not be performed even if an exception occurs while processing the response.
  • The synchronous, if there is no exception in the process of sending, but send the result is not OK, will choose another broker also continue to retry (need to open the configuration items: retryAnotherBrokerWhenNotStoreOK)
  • Sequential messages fail to be sent without retry. Sequential messages are sent synchronously and in a specified message queue
  • Asynchronous + specified way of message queue to send, don’t think that is order to send, because the asynchronous send there is no guarantee that the message sequence, although in the process of sending abnormal not retry, but sent after the completion of the processing logic and the asynchronous way, if the state does not meet the specified conditions, will continue to retry, with asynchronous transmission process
  • In one-way mode, the system does not wait for the result. Therefore, the system does not consider whether to retry after the result is returned. However, the system retries exceptions in one-way mode, just as in synchronous mode

Retry logic code

Retry logic in: Source org. Apache. Rocketmq. Client. Impl. Producer. DefaultMQProducerImpl# sendDefaultImpl (Message MSG, final CommunicationMode communicationMode,final SendCallback sendCallback,final long timeout)

SendDefaultImpl ->sendKernelImpl. The retry logic is in sendDefaultImpl. SendDefaultImpl fails to be sent and sendKernelImpl is called again. Send message ->sendKernelImpl, so there is no logical retry message send retry at queue selection time, if there are multiple Broker masters, the next retry broker will be different from the last one

The producer flow control does not retry

If the message fails to be sent by flow control, retry will not be performed. The following is an excerpt from the official documentation.

Producer flow control as broker processing capacity reaches a bottleneck; Consumer flow control, as consumption capacity reached a bottleneck. Producer flow control:

  • CommitLog file locked time exceeds osPageCacheBusyTimeOutMills, parameter defaults to 1000 ms, return flow control.
  • If transientStorePoolEnable == true is enabled, the broker is an asynchronous host, and transientStorePool resources are insufficient, the current SEND request is rejected and flow control is returned.
  • The broker checks the wait time at the head of the send queue every 10ms. If the wait time exceeds waitTimeMillsInSendQueue, the default is 200ms. The broker rejects the send request and returns to flow control.
  • The broker controls traffic by rejecting send requests. Note that producer flow control does not attempt message recasting. Consumer flow control:
  • The default is 1000 when the number of messages cached locally by the consumer exceeds the pullThresholdForQueue.
  • Consumer message size than pullThresholdSizeForQueue local cache, the default 100 MB.
  • Consumer message span over consumeConcurrentlyMaxSpan local cache, 2000 by default. The result of consumer flow control is reduced pull frequency.

Exception that allows retry when sending

• RemotingException • MQClientException • MQBrokerException, the following ResponseCode will not be retried: case responsecode.topic_not_exist: case ResponseCode.SERVICE_NOT_AVAILABLE: case ResponseCode.SYSTEM_ERROR: case ResponseCode.NO_PERMISSION: case ResponseCode.NO_BUYER_ID: case ResponseCode.NOT_IN_CURRENT_UNIT:Copy the code

MQBrokerException is in the message sending result, FLUSH_DISK_TIMEOUT, responsecode. FLUSH_SLAVE_TIMEOUT, responsecode. SLAVE_NOT_AVAILABLE, Response Code.success) will throw the exception.

Status code returned by the broker flow control: RemotingSysResponseCode SYSTEM_BUSY (not retry)