Xushaohong commented on code in PR #4939:
URL: https://github.com/apache/ozone/pull/4939#discussion_r1244801023
##########
hadoop-hdds/server-scm/src/main/java/org/apache/hadoop/hdds/scm/block/SCMBlockDeletingService.java:
##########
@@ -273,4 +279,24 @@ public void stop() {
public ScmBlockDeletingServiceMetrics getMetrics() {
return this.metrics;
}
+
+ /**
+ * Filters and returns a set of healthy datanodes that have not exceeded
+ * the deleteBlocksPendingCommandLimit.
+ *
+ * @param datanodes a list of DatanodeDetails
+ * @return a set of filtered DatanodeDetails
+ */
+ @VisibleForTesting
+ protected Set<DatanodeDetails> getDatanodesWithinCommandLimit(
+ List<DatanodeDetails> datanodes) throws NodeNotFoundException {
+ final Set<DatanodeDetails> included = new HashSet<>();
+ for (DatanodeDetails dn : datanodes) {
+ if (nodeManager.getTotalDatanodeCommandCount(dn,
Review Comment:
I see. Most of the time it should be fine.
The worst case:
A If DN reported the HB at time A with a full cmd
queue.
A+ 29.9s. SCM DeletedBlockTransactionScanner executes and cannot send
cmd to DN, needs to wait for next
round.
A+ 90s. SCM has updated the latest HB from DN and
DeletedBlockTransactionScanner executes, and finally
send cmd to DN again.
It could lead to at most a 90-sec gap.
Right now it seems to be trivial compared to the interval of
DeletedBlockTransactionScanner.
Thx for the explanation.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
