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

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

hadoop-yetus commented on PR #8345:
URL: https://github.com/apache/hadoop/pull/8345#issuecomment-4060659465

   :broken_heart: **-1 overall**
   
   
   
   
   
   
   | Vote | Subsystem | Runtime |  Logfile | Comment |
   |:----:|----------:|--------:|:--------:|:-------:|
   | +0 :ok: |  reexec  |   0m  0s |  |  Docker mode activated.  |
   | -1 :x: |  patch  |   0m 25s |  |  
https://github.com/apache/hadoop/pull/8345 does not apply to trunk. Rebase 
required? Wrong Branch? See 
https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute for help.  
|
   
   
   | Subsystem | Report/Notes |
   |----------:|:-------------|
   | Console output | 
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8345/1/console |
   | versions | git=2.34.1 |
   | Powered by | Apache Yetus 0.14.1 https://yetus.apache.org |
   
   
   This message was automatically generated.
   
   




> RBF: permit not released during invokeConcurrent if getOrderedNamenodes 
> throws an exception
> -------------------------------------------------------------------------------------------
>
>                 Key: HDFS-17892
>                 URL: https://issues.apache.org/jira/browse/HDFS-17892
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: rbf
>    Affects Versions: 3.4.3
>            Reporter: Dimas Shidqi Parikesit
>            Priority: Critical
>              Labels: pull-request-available
>
> After [HDFS-17265|https://issues.apache.org/jira/browse/HDFS-17265], we 
> either move acquirePermit after getOrderedNamenodes or wrap 
> getOrderedNamenodes in a try-finally block so that the permit can be released 
> if getOrderedNamenodes throws an exception.
> However, the behavior of the latest trunk (a178eb7) has regressed, where we 
> don't handle the permit release anymore.
> The test failed to detect this problem because it only use 1 locations. In 
> invokeConcurrent, the execution flows into invokeSingle where the exception 
> is correctly handled using this branch
> ```
> else if (locations.size() == 1 && timeOutMs <= 0) {
>       // Shortcut, just one call
>       return invokeSingle(locations.iterator().next(), method);
>     }
> ```
> In this patch, I've fixed the invokeConcurrent and the test to reflect this 
> behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to