[jira] [Commented] (HDFS-17902) StripedBlockChecksumReconstructor leaks connections on init failure

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HDFS-17902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069524#comment-18069524 ] 

ASF GitHub Bot commented on HDFS-17902:
---------------------------------------

CapMoon opened a new pull request, #8393:
URL: https://github.com/apache/hadoop/pull/8393

   HDFS-17902. StripedBlockChecksumReconstructor leaks connections on init failure
   
   ### Description of PR
   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.




> 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
>
> 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: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org