[ 
https://issues.apache.org/jira/browse/HDFS-16703?focusedWorklogId=796609&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-796609
 ]

ASF GitHub Bot logged work on HDFS-16703:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 30/Jul/22 12:46
            Start Date: 30/Jul/22 12:46
    Worklog Time Spent: 10m 
      Work Description: slfan1989 commented on PR #4660:
URL: https://github.com/apache/hadoop/pull/4660#issuecomment-1200151395

   @ZanderXu I feel that this change is a bit risky, will this lead to 
instability of the service? Sometimes it is reasonable to configure without 
timeout. The main question is is it reasonable to use the same timeout 
configuration for different protocols?




Issue Time Tracking
-------------------

    Worklog Id:     (was: 796609)
    Time Spent: 0.5h  (was: 20m)

> Enable RPC Timeout for some protocols of NameNode.
> --------------------------------------------------
>
>                 Key: HDFS-16703
>                 URL: https://issues.apache.org/jira/browse/HDFS-16703
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: ZanderXu
>            Assignee: ZanderXu
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When I read some code about protocol, I found that only 
> ClientNamenodeProtocolPB proxy with RPC timeout, other protocolPB proxy 
> without RPC timeout, such as RefreshAuthorizationPolicyProtocolPB, 
> RefreshUserMappingsProtocolPB, RefreshCallQueueProtocolPB, 
> GetUserMappingsProtocolPB and NamenodeProtocolPB.
>  
> If proxy without rpc timeout,  it will be blocked for a long time if the NN 
> machine crash or bad network during writing or reading with NN. 
>  
> So I feel that we should enable RPC timeout for all ProtocolPB.



--
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