[ 
https://issues.apache.org/jira/browse/HDFS-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Íñigo Goiri resolved HDFS-17067.
--------------------------------
    Fix Version/s: 3.4.0
     Hadoop Flags: Reviewed
       Resolution: Fixed

> Use BlockingThreadPoolExecutorService for nnProbingThreadPool in 
> ObserverReadProxy
> ----------------------------------------------------------------------------------
>
>                 Key: HDFS-17067
>                 URL: https://issues.apache.org/jira/browse/HDFS-17067
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs
>    Affects Versions: 3.4.0
>            Reporter: Xing Lin
>            Assignee: Xing Lin
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 3.4.0
>
>
> In HDFS-17030, we introduced an ExecutorService, to submit 
> getHAServiceState() requests. We constructed the ExecutorService directly 
> from a basic ThreadPoolExecutor, without setting _allowCoreThreadTimeOut_ to 
> true. Then, the core thread will be kept up and running even when the main 
> thread exits. To fix it, one could set _allowCoreThreadTimeOut_ to true. 
> However, in this PR, we decide to directly use an existing executorService 
> implementation (_BlockingThreadPoolExecutorService_) in hadoop instead. It 
> takes care of setting _allowCoreThreadTimeOut_ and also allows setting the 
> prefix for thread names.
> {code:java}
>   private final ExecutorService nnProbingThreadPool =
>       new ThreadPoolExecutor(1, 4, 1L, TimeUnit.MINUTES,
>           new ArrayBlockingQueue<Runnable>(1024));
> {code}
> A second minor issue is we did not shutdown the executorService in close(). 
> It is a minor issue as close() will only be called when the garbage collector 
> starts to reclaim an ObserverReadProxyProvider object, not when there is no 
> reference to the ObserverReadProxyProvider object. The time between when an 
> ObserverReadProxyProvider becomes dereferenced and when the garage collector 
> actually starts to reclaim that object is out of control/under-defined 
> (unless the program is shutdown with an explicit System.exit(1)).



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

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to