Return-Path: 
 <common-issues-return-30333-apmail-hadoop-common-issues-archive=hadoop.apache.org@hadoop.apache.org>
X-Original-To: apmail-hadoop-common-issues-archive@minotaur.apache.org
Delivered-To: apmail-hadoop-common-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 43F3FC2C4
	for <apmail-hadoop-common-issues-archive@minotaur.apache.org>;
 Fri, 27 Apr 2012 12:08:14 +0000 (UTC)
Received: (qmail 19238 invoked by uid 500); 27 Apr 2012 12:08:14 -0000
Delivered-To: apmail-hadoop-common-issues-archive@hadoop.apache.org
Received: (qmail 19212 invoked by uid 500); 27 Apr 2012 12:08:14 -0000
Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:common-issues-help@hadoop.apache.org>
List-Unsubscribe: <mailto:common-issues-unsubscribe@hadoop.apache.org>
List-Post: <mailto:common-issues@hadoop.apache.org>
List-Id: <common-issues.hadoop.apache.org>
Reply-To: common-issues@hadoop.apache.org
Delivered-To: mailing list common-issues@hadoop.apache.org
Received: (qmail 19204 invoked by uid 99); 27 Apr 2012 12:08:13 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Apr 2012 12:08:13 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Apr 2012 12:08:11 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id 6B17642384F
	for <common-issues@hadoop.apache.org>; Fri, 27 Apr 2012 12:07:50 +0000 (UTC)
Date: Fri, 27 Apr 2012 12:07:50 +0000 (UTC)
From: "Jim Donofrio (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: 
 <267102288.2534.1335528470491.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1360700805.1758.1335510592299.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HADOOP-8323) Revert HADOOP-7940
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/HADOOP-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263592#comment-13263592 ] 

Jim Donofrio commented on HADOOP-8323:
--------------------------------------

> Clear call ought to clear memory and thats what this change actually intends to do (though the test case may lead you astray - filed HADOOP-8324).
> The current javadocs indeed cover the getBytes usage behavior as you've pointed out. So if you'd like to keep the size in its increased state, why clear() it?

    /**
     * Resets the <code>count</code> field of this byte array output
     * stream to zero, so that all currently accumulated output in the
     * output stream is discarded. The output stream can be used again,
     * reusing the already allocated buffer space.
     *
     * @see     java.io.ByteArrayInputStream#count
     */
    public synchronized void reset() {
        count = 0;
    }

I would like to clear it so that the next time I call append, it will start at the beginning of the internal array without having to scale up the size of the array again. The ByteArrayOutputStream class in java.io which is every similar to Text has a reset method similar to clear that just sets the internal length to 0 instead of freeing the allocated internal buffer.

However, I understand the need to free memory so why not leave clear as it is and add a clearBytes method which sets the length to 0 and sets the bytes to EMPTY_BYTES.
                
> Revert HADOOP-7940
> ------------------
>
>                 Key: HADOOP-8323
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8323
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: io
>    Affects Versions: 2.0.0
>            Reporter: Harsh J
>            Assignee: Harsh J
>            Priority: Critical
>
> Per [~jdonofrio]'s comments on HADOOP-7940, we should revert it as it has caused a performance regression (for scenarios where Text is reused, popular in MR).
> The clear() works as intended, as the API also offers a current length API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira