hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hairong Kuang (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-2757) Should DFS outputstream's close wait forever?
Date Wed, 20 May 2009 18:43:46 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711288#action_12711288

Hairong Kuang commented on HADOOP-2757:

1. rpc timeout: the patch seems to implement a read timeout not rpc timeout. If we want to
implement rpc timeout, the start wait time should set in the beginning of receiveResponse.
2. if we have rpc timeout, why we still need soft mount timeout in leaseChecker? 
3 I think the check "if (now > last + softMountTimeout) " could easily be true in normal
cases if renewFrenquency is set to be the soft mount timeout.
3. I feel that the meaning of soft mount timeout is not clear maybe because I am not familiar
with NFS terms. Does this limit the maximum time of each file system method or does not limit
the maximum time for each call to NN?  First of all this patch applies this timeout to only
two cases: file close and leaseChecker. The file close case seems to limit the maximum time
to a filesystem method. The leaseChecker case seems to limit the maximum time for a rpc although
not exactly. 
4. In the file close case, would it be better just to limit the number of retires?

> Should DFS outputstream's close wait forever?
> ---------------------------------------------
>                 Key: HADOOP-2757
>                 URL: https://issues.apache.org/jira/browse/HADOOP-2757
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: dfs
>            Reporter: Raghu Angadi
>            Assignee: dhruba borthakur
>         Attachments: softMount1.patch, softMount1.patch, softMount2.patch, softMount3.patch
> Currently {{DFSOutputStream.close()}} waits for ever if Namenode keeps throwing {{NotYetReplicated}}
exception, for whatever reason. Its pretty annoying for a user. Shoud the loop inside close
have a timeout? If so how much? It could probably something like 10 minutes.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message