[jira] [Updated] (HADOOP-12827) WebHdfs socket timeouts should be configurable

["Austin Donnelly (JIRA)" <ji...@apache.org>]

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

Austin Donnelly updated HADOOP-12827:
-------------------------------------
    Status: Patch Available  (was: Open)

Here's a patch which fixes this issue.

Testing: no new test code added, since this only adds two config options.

Manual testing: I tested the following scenarios:
 * New config not present.  Client timeout verified unchanged at 60s.
 * New config present: 30s for connect timeout, 2m for read timeout:
     - WebHdfs server not listening => client timeout at 30s as expected.
     - WebHdfs server up, but modified to stall data => client timeout at 2m as expected.
     - WebHdfs server up, operating normally => client operates normally.
 * Also tested with distCp.  Before patch, some transfers would timeout, after patch, set longer (30m) read timeout, and distCp completes without timeouts.

> WebHdfs socket timeouts should be configurable
> ----------------------------------------------
>
>                 Key: HADOOP-12827
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12827
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: fs
>         Environment: all
>            Reporter: Austin Donnelly
>            Assignee: Austin Donnelly
>              Labels: easyfix, newbie
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> WebHdfs client connections use sockets with fixed timeouts of 60 seconds to connect, and 60 seconds for reads.
> This is a problem because I am trying to use WebHdfs to access an archive storage system which can take minutes to hours to return the requested data over WebHdfs.
> The fix is to add new configuration file options to allow these 60s defaults to be customised in hdfs-site.xml.
> If the new configuration options are not present, the behavior is unchanged from before.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)