Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 43C01107AD for ; Fri, 27 Dec 2013 17:44:12 +0000 (UTC) Received: (qmail 67899 invoked by uid 500); 27 Dec 2013 17:43:13 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 67713 invoked by uid 500); 27 Dec 2013 17:42:59 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 67669 invoked by uid 99); 27 Dec 2013 17:42:54 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Dec 2013 17:42:54 +0000 Date: Fri, 27 Dec 2013 17:42:54 +0000 (UTC) From: "Uma Maheswara Rao G (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Reopened] (HDFS-5697) connection leak in DFSInputStream MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswara Rao G reopened HDFS-5697: --------------------------------------- > connection leak in DFSInputStream > --------------------------------- > > Key: HDFS-5697 > URL: https://issues.apache.org/jira/browse/HDFS-5697 > Project: Hadoop HDFS > Issue Type: Bug > Reporter: Haitao Yao > Attachments: HDFS-5697.patch, HDFS-5697.patch > > > While getting the BlockReader from DFSInputStream, if the cache is miss, the DFSInputStream creates a new peer. But if error occured when creating the new blockreader with the give peer and IOException is thrown, the created peer is not closed and will cause too many CLOSE-WAIT status. > here's the stacktrace: > java.io.IOException: Got error for OP_READ_BLOCK, self=/10.130.100.32:26657, remote=/10.130.100.32:50010, for file /hbase/STAT_RESULT_SALT/d17e9cf1d1de34910bc6724c7cc21ed8/_0/c75770dbed6444488b609385e8bc9e0d, for pool BP-2041309608-10.130.100.157-1361861188734 block -7893680960325255689_107620083 > at org.apache.hadoop.hdfs.RemoteBlockReader2.checkSuccess(RemoteBlockReader2.java:429) > at org.apache.hadoop.hdfs.RemoteBlockReader2.newBlockReader(RemoteBlockReader2.java:394) > at org.apache.hadoop.hdfs.BlockReaderFactory.newBlockReader(BlockReaderFactory.java:137) > at org.apache.hadoop.hdfs.DFSInputStream.getBlockReader(DFSInputStream.java:1103) > at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:538) > at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:750) > at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:794) > at java.io.DataInputStream.read(DataInputStream.java:149) > at org.apache.hadoop.io.IOUtils.readFully(IOUtils.java:192) > at org.apache.hadoop.hbase.io.hfile.HFileBlock$AbstractFSReader.readAtOffset(HFileBlock.java:1409) > at org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderV2.readBlockDataInternal(HFileBlock.java:1921) > at org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderV2.readBlockData(HFileBlock.java:1703) > at org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:338) > at org.apache.hadoop.hbase.io.hfile.HFileReaderV2$EncodedScannerV2.seekTo(HFileReaderV2.java:997) > at org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:229) > at org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:145) > at org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:165) > So there should be a catch clause at the end of the function to check if IOException is thrown , the peer should be closed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)