Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Sat, 25 Apr 2015 00:11:39 +0000 (UTC)
From: "Nick Dimiduk (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12739582.1409948296000.24854.1429920699807@Atlassian.JIRA>
In-Reply-To: <JIRA.12739582.1409948296000@Atlassian.JIRA>
References: <JIRA.12739582.1409948296000@Atlassian.JIRA>
 <JIRA.12739582.1409948296576@arcas>
Subject: [jira] [Commented] (HDFS-7005) DFS input streams do not timeout
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14512071#comment-14512071 ] 

Nick Dimiduk commented on HDFS-7005:
------------------------------------

Hi [~kasha]. Thanks again for the offer. HBase community has decided to lax it's position [0] on dependency project version changes for the time being and will release 1.1 against Hadoop 2.6.0. In general, we would appreciate a release patch cadence that includes bug fixes that do not impact user-facing APIs and wire compatibility in addition to security fixes. However this is probably a discussion for a wider audience.

[0]: http://markmail.org/message/4sv4hapzxkeqbk3d

> DFS input streams do not timeout
> --------------------------------
>
>                 Key: HDFS-7005
>                 URL: https://issues.apache.org/jira/browse/HDFS-7005
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs-client
>    Affects Versions: 3.0.0, 2.5.0
>            Reporter: Daryn Sharp
>            Assignee: Daryn Sharp
>            Priority: Critical
>             Fix For: 2.6.0
>
>         Attachments: HDFS-7005.patch
>
>
> Input streams lost their timeout.  The problem appears to be {{DFSClient#newConnectedPeer}} does not set the read timeout.  During a temporary network interruption the server will close the socket, unbeknownst to the client host, which blocks on a read forever.
> The results are dire.  Services such as the RM, JHS, NMs, oozie servers, etc all need to be restarted to recover - unless you want to wait many hours for the tcp stack keepalive to detect the broken socket.


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