[
https://issues.apache.org/jira/browse/HDFS-17902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071938#comment-18071938
]
ASF GitHub Bot commented on HDFS-17902:
---------------------------------------
ZanderXu commented on code in PR #8393:
URL: https://github.com/apache/hadoop/pull/8393#discussion_r3050980434
##########
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/erasurecode/StripedBlockChecksumReconstructor.java:
##########
@@ -52,7 +52,13 @@ protected
StripedBlockChecksumReconstructor(ErasureCodingWorker worker,
assert targetIndices != null;
this.checksumWriter = checksumWriter;
this.requestedLen = requestedBlockLength;
- init();
+ try {
Review Comment:
refer to the class `StripedBlockReconstructor`.
How about moving the `init()` out of the constructor and calling it before
using `reconstruct()`?
```
try (StripedBlockChecksumReconstructor checksumRecon =
groupChecksumType == BlockChecksumType.COMPOSITE_CRC ?
new StripedBlockChecksumCompositeCrcReconstructor(
getDatanode().getErasureCodingWorker(), stripedReconInfo,
blockChecksumBuf, blockLength) :
new StripedBlockChecksumMd5CrcReconstructor(
getDatanode().getErasureCodingWorker(), stripedReconInfo,
blockChecksumBuf, blockLength)) {
// Here
checksumRecon.init();
checksumRecon.reconstruct();
...
}
```
> StripedBlockChecksumReconstructor leaks connections on init failure
> -------------------------------------------------------------------
>
> Key: HDFS-17902
> URL: https://issues.apache.org/jira/browse/HDFS-17902
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
> Affects Versions: 3.4.3
> Reporter: yue.wang
> Priority: Major
> Labels: pull-request-available
>
> When BlockGroupNonStripedChecksumComputer.recalculateChecksum() allocates a
> StripedBlockChecksumReconstructor with try-with-resources, the
> reconstructor's constructor calls StripedReconstructor's superclass
> constructor first, which creates a StripedReader. The constructor then calls
> getStripedReader().init(), which in turn calls initReaders().
> If initReaders() fails because nSuccess < minRequiredSources, it throws
> IOException. initReaders() does not close StripedBlockReader instances that
> were already created and may already hold open block/TCP connections to peer
> DataNodes.
> Because the constructor throws before the StripedBlockChecksumReconstructor
> instance is successfully created, the try-with-resources statement never
> assigns the resource variable and therefore does not invoke Closeable.close()
> on the reconstructor (JLS: resource is only closed if initialization
> completes normally). As a result, StripedReader.close() is never called on
> that code path, and connections opened during the failed initReaders() loop
> can leak.
> By contrast, StripedBlockReconstructor.run() always calls
> getStripedReader().close() in a finally block, so the same failure mode is
> cleaned up there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]