You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Hairong Kuang (JIRA)" <ji...@apache.org> on 2009/05/20 20:43:46 UTC

[jira] Commented: (HADOOP-2757) Should DFS outputstream's close wait forever?

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