[
https://issues.apache.org/jira/browse/HDFS-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906188#action_12906188
]
Jakob Homan commented on HDFS-1353:
-----------------------------------
Ran tests manually. All past except known bad TestHDFSTrash and
TestFileConcurrentReader. Test-patch:
{noformat}
[exec] -1 overall.
[exec]
[exec] +1 @author. The patch does not contain any @author tags.
[exec]
[exec] +1 tests included. The patch appears to include 3 new or
modified tests.
[exec]
[exec] -1 javadoc. The javadoc tool appears to have generated 1
warning messages.
[exec]
[exec] +1 javac. The applied patch does not increase the total number
of javac compiler warnings.
[exec]
[exec] +1 findbugs. The patch does not introduce any new Findbugs
warnings.
[exec]
[exec] +1 release audit. The applied patch does not increase the
total number of release audit warnings.
[exec]
[exec] +1 system tests framework. The patch passed system tests
framework compile.
{noformat}
Javadoc warning has been around and is bogus. I plan to commit this.
> Remove most of getBlockLocation optimization
> --------------------------------------------
>
> Key: HDFS-1353
> URL: https://issues.apache.org/jira/browse/HDFS-1353
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: name-node
> Affects Versions: 0.21.0
> Reporter: Jakob Homan
> Assignee: Jakob Homan
> Fix For: 0.21.1, 0.22.0
>
> Attachments: Benchmarking results.xlsx, HDFS-1353-y20.patch,
> HDFS-1353.patch
>
>
> <This description is not valid. See comment.>
> HDFS-1081 optimized the number of block access tokens (BATs) created in a
> single call to getBlockLocations, as this is an expensive operation.
> However, that JIRA put off another optimization which was then made possible,
> which is to just send a single block access token across the wire (and
> maintain a single BAT on the client side). This JIRA is for implementing
> that optimization. Since a single BAT is generated for all the blocks, we
> just write that single BAT to the wire, rather than writing n BATs for n
> blocks, as is currently done. This turns out to be a useful optimization for
> files with very large numbers of blocks, as the new lone BAT is much larger
> than was a BAT previously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.