Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 71877 invoked from network); 20 Feb 2008 20:38:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Feb 2008 20:38:23 -0000 Received: (qmail 77540 invoked by uid 500); 20 Feb 2008 20:38:16 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 77529 invoked by uid 500); 20 Feb 2008 20:38:16 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 77520 invoked by uid 99); 20 Feb 2008 20:38:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Feb 2008 12:38:16 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Feb 2008 20:37:38 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 731D9234C04D for ; Wed, 20 Feb 2008 12:37:44 -0800 (PST) Message-ID: <512604503.1203539864470.JavaMail.jira@brutus> Date: Wed, 20 Feb 2008 12:37:44 -0800 (PST) From: "Raghu Angadi (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Created: (HADOOP-2863) FSDataOutputStream should not flush() inside close(). MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org FSDataOutputStream should not flush() inside close(). ----------------------------------------------------- Key: HADOOP-2863 URL: https://issues.apache.org/jira/browse/HADOOP-2863 Project: Hadoop Core Issue Type: Bug Components: fs Reporter: Raghu Angadi Fix For: 0.17.0 Why does FSDataOutputStream.close() call flush()? This stream itself does not store any data that it needs to flush. It is a wrapper and it should just invoke its outputstream's close(). For. e.g one bad side effect is that, in the case of DFSOutputStream which extends FSOutputSummer, flush() inside close sends the current data even though FSOutputSummer might have some data.. this left over data will be sent in side close() (so it sends data in two different packets instead of one). Other filesystems might have similar side effects. I will submit a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.