RongtongJin commented on code in PR #6568:
URL: https://github.com/apache/rocketmq/pull/6568#discussion_r1163532994
##########
client/src/main/java/org/apache/rocketmq/client/impl/producer/DefaultMQProducerImpl.java:
##########
@@ -153,6 +157,38 @@ public DefaultMQProducerImpl(final DefaultMQProducer
defaultMQProducer, RPCHook
semaphoreAsyncSendSize = new Semaphore(1024 * 1024, true);
log.info("semaphoreAsyncSendSize can not be smaller than 1M.");
}
+
+ ServiceDetector serviceDetector = new ServiceDetector() {
+ @Override
+ public boolean detect(String endpoint, long timeoutMillis) {
+ Optional<String> candidateTopic = pickTopic();
+ if (!candidateTopic.isPresent()) {
+ return false;
+ }
+ try {
+ MessageQueue mq = new MessageQueue(candidateTopic.get(),
null, 0);
+ mQClientFactory.getMQClientAPIImpl()
+ .getMaxOffset(endpoint, mq, timeoutMillis);
+ return true;
+ } catch (Exception e) {
+ return false;
+ }
+ }
+ };
Review Comment:
When there are many clients (such as 1 million producers or consumers, which
by default probe every broker every 3 seconds), is GetMaxOffset a relatively
heavy operation? Could it put pressure on the broker? Here are my two
suggestions:
1.The RemotingClient's isAddressReachable method could be used to complete
connection detection and check if the long connection channel is normal, which
is lighter weight.
2.If it is necessary to check if the broker's execution logic is normal,
could it be replaced with VIEW_BROKER_STATS_DATA? This request does not require
topic or message queue related data and does not involve the store layer.
--
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]
