shengminw opened a new issue, #4552:
URL: https://github.com/apache/rocketmq/issues/4552
There are asynchronous sending methods in the current message asysending
mechanism:
```java
ExecutorService executor = this.getAsyncSenderExecutor();
try {
executor.submit(new Runnable() {
@Override
public void run() {
long costTime = System.currentTimeMillis() - beginStartTime;
if (timeout > costTime) {
try {
sendDefaultImpl(msg, CommunicationMode.ASYNC,
sendCallback, timeout - costTime);
} catch (Exception e) {
sendCallback.onException(e);
}
} else {
sendCallback.onException(
new RemotingTooMuchRequestException("DEFAULT ASYNC send
call timeout"));
}
}
});
} catch (RejectedExecutionException e) {
throw new MQClientException("executor rejected ", e);
}
```
When the upstream sending message traffic is too large, the thread pool will
directly refuse to execute and throw MQClientException.
In this case, the users need to implement a traffic-limit mechanism by
themselves, usually putting the sending thread to sleep for a period of time
before sending again. However, this may not be a good solution.
That is to say, asynchronous sending requires a back pressure mechanism.
Within the timeout allowed by the client, the SDK needs to block the sending
operation.
This problem is relatively easy to trigger in data synchronization and log
collection scenarios.
--
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]
