Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Date: Thu, 12 Apr 2012 17:21:23 +0000 (UTC)
From: "Todd Lipcon (Resolved) (JIRA)" <jira@apache.org>
To: common-dev@hadoop.apache.org
Message-ID: 
 <1640604095.18128.1334251283272.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1548652738.17984.1334249717190.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (HADOOP-8272) BytesWritable length problem
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HADOOP-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Todd Lipcon resolved HADOOP-8272.
---------------------------------

    Resolution: Invalid

This is not a bug - this is the expected behavior of getBytes(). Please refer to the javadoc:
{code}

  /**
   * Get the data backing the BytesWritable. Please use {@link #copyBytes()}
   * if you need the returned array to be precisely the length of the data.
   * @return The data is only valid between 0 and getLength() - 1.
   */
{code}
                
> BytesWritable length problem
> ----------------------------
>
>                 Key: HADOOP-8272
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8272
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: io
>    Affects Versions: 0.20.205.0
>            Reporter: Simon Gilliot
>              Labels: hadoop
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I tried to create my own Writable which contains a BytesWritable.
> In my conctructor, I tried to create an empty BytesWritable :
> BytesWritable key = new BytesWritable();
> Next, in my readFields, I did :
> key.readFields(in); LOG.debug(Bytes.toString(key.getBytes()));
> The key contains much more bytes than I had wrote.
> In fact, if my BytesWritable contains 100 bytes, I thing that the readFields() of BytesWritable call :
> * setSize(0) (which seems useless since the values in the old range are preserved and any new values are undefined). * setSize(100) which extends the bytes array (by setCapacity) to 1.5 * the size (so 150) without initalizing it
> * readFully(bytes, 0, 100) which fill the bytes array from '0' to '100' offsets.
> And when I call getBytes() on it, the bytes array of 150 bytes is returned without any control.
> That seems possible that the same problem happens in other conditions, when we increase ths bytes array size.

--
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