[
https://issues.apache.org/jira/browse/HADOOP-11039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253417#comment-14253417
]
Hadoop QA commented on HADOOP-11039:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12665690/HADOOP-11039.001.patch
against trunk revision 6635ccd.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5317//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5317//artifact/patchprocess/newPatchFindbugsWarningshadoop-common.html
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5317//console
This message is automatically generated.
> ByteBufferReadable API doc is inconsistent with the implementations.
> --------------------------------------------------------------------
>
> Key: HADOOP-11039
> URL: https://issues.apache.org/jira/browse/HADOOP-11039
> Project: Hadoop Common
> Issue Type: Bug
> Components: documentation
> Reporter: Yi Liu
> Assignee: Yi Liu
> Priority: Minor
> Attachments: HADOOP-11039.001.patch
>
>
> In {{ByteBufferReadable}}, API doc of {{int read(ByteBuffer buf)}} says:
> {quote}
> After a successful call, buf.position() and buf.limit() should be unchanged,
> and therefore any data can be immediately read from buf. buf.mark() may be
> cleared or updated.
> {quote}
> {quote}
> @param buf
> the ByteBuffer to receive the results of the read operation.
> Up to
> buf.limit() - buf.position() bytes may be read.
> {quote}
> But actually the implementations (e.g. {{DFSInputStream}},
> {{RemoteBlockReader2}}) would be:
> *Upon return, buf.position() will be advanced by the number of bytes read.*
> code implementation of {{RemoteBlockReader2}} is as following:
> {code}
> @Override
> public int read(ByteBuffer buf) throws IOException {
> if (curDataSlice == null || curDataSlice.remaining() == 0 &&
> bytesNeededToFinish > 0) {
> readNextPacket();
> }
> if (curDataSlice.remaining() == 0) {
> // we're at EOF now
> return -1;
> }
> int nRead = Math.min(curDataSlice.remaining(), buf.remaining());
> ByteBuffer writeSlice = curDataSlice.duplicate();
> writeSlice.limit(writeSlice.position() + nRead);
> buf.put(writeSlice);
> curDataSlice.position(writeSlice.position());
> return nRead;
> }
> {code}
> This description is very important and will guide user how to use this API,
> and all the implementations should keep the same behavior. We should fix the
> javadoc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
