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 Tue, 26 May 2009 21:11:45 GMT

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

Hairong Kuang commented on HADOOP-2757:

> As an administrator of a cluster, I find it easier to set a time limit for a rpc conection
to bail out if it is not receiving response data continuously.

I am not sure if all administrators want this. This is going to revert what we did in HADOOP-2188.
IPC client already has a configured read timeout. If you do want a timeout on read,  maybe
it is better to have a configuration setting if the client needs a Ping or not. There is no
need to have multiple read timeout configurations.

Suppose RPC can fail on SocketTimeoutException, why you need a timeout on a single RPC? Why
can't the client close the lease on SocketTimeoutException?  I think one timeout and a hard
retry limitation on close will serve your purpose well. Why we need so many different layers
of timeout? Maybe I missed something.

BTW, the configurations inactivity.timeout and softmount.timeout are not general at all. One
is only for leasechecker and anotther is only for close.

> 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