Copilot commented on code in PR #11062:
URL: https://github.com/apache/ozone/pull/11062#discussion_r3813007802
##########
hadoop-ozone/integration-test-recon/src/test/java/org/apache/hadoop/ozone/recon/TestReconTasks.java:
##########
@@ -340,9 +340,9 @@ public void
testContainerHealthTaskDetectsUnderReplicatedAfterNodeFailure()
* <p>Classification logic: When a CLOSING container has zero replicas,
* {@code ClosingContainerHandler} samples it as {@code MISSING}. Then
* {@code handleMissingContainer()} calls {@code isEmptyMissing()} which
checks
- * {@link ContainerInfo#getNumberOfKeys()}. Since the container was created
via
- * XceiverClient bypassing Ozone Manager, SCM's key count is 0, so the
container
- * is classified as {@code EMPTY_MISSING} rather than {@code MISSING}.</p>
+ * {@link ContainerInfo#getNumberOfKeys()}. The container is created empty
(no block is written), so the
+ * datanode reports a replica key count of 0 and Recon's {@link
ContainerInfo} key count stays 0, so the
+ * container is classified as {@code EMPTY_MISSING} rather than {@code
MISSING}.</p>
Review Comment:
The new comments mix the terms “block count” and
`ContainerInfo#getNumberOfKeys()`/“key count”. Since the classification is
based on `numberOfKeys`, it would be clearer and less error-prone to describe
the propagation consistently in terms of `numberOfKeys` (or explicitly explain
the relationship between block count and `numberOfKeys` if they are
intentionally coupled).
##########
hadoop-ozone/integration-test-recon/src/test/java/org/apache/hadoop/ozone/recon/TestReconTasks.java:
##########
@@ -365,8 +365,11 @@ public void
testContainerHealthTaskDetectsEmptyMissingWhenAllReplicasLost()
long containerID = containerInfo.getContainerID();
Pipeline pipeline =
scmPipelineManager.getPipeline(containerInfo.getPipelineID());
+ // Do NOT write a block here: container reports propagate the datanode's
block count into
+ // ContainerInfo#numberOfKeys, and a non-zero key count yields MISSING
instead of EMPTY_MISSING.
XceiverClientGrpc client = new XceiverClientGrpc(pipeline, conf);
- runTestOzoneContainerViaDataNode(containerID, client);
+ client.connect();
+ createContainerForTesting(client, containerID);
Review Comment:
`client.connect()` is introduced here, but this snippet does not show any
corresponding close/shutdown. If `XceiverClientGrpc` is not closed elsewhere in
the method (including exceptional paths), this can leak resources
(channels/threads) and make the test suite less stable. Prefer wrapping the
client lifecycle in try/finally (or try-with-resources if supported) to ensure
it is always closed.
##########
hadoop-ozone/integration-test-recon/src/test/java/org/apache/hadoop/ozone/recon/TestReconTasks.java:
##########
@@ -365,8 +365,11 @@ public void
testContainerHealthTaskDetectsEmptyMissingWhenAllReplicasLost()
long containerID = containerInfo.getContainerID();
Pipeline pipeline =
scmPipelineManager.getPipeline(containerInfo.getPipelineID());
+ // Do NOT write a block here: container reports propagate the datanode's
block count into
+ // ContainerInfo#numberOfKeys, and a non-zero key count yields MISSING
instead of EMPTY_MISSING.
Review Comment:
The new comments mix the terms “block count” and
`ContainerInfo#getNumberOfKeys()`/“key count”. Since the classification is
based on `numberOfKeys`, it would be clearer and less error-prone to describe
the propagation consistently in terms of `numberOfKeys` (or explicitly explain
the relationship between block count and `numberOfKeys` if they are
intentionally coupled).
--
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]
