hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Boudnik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HDFS-516) Low Latency distributed reads
Date Mon, 03 Aug 2009 18:03:17 GMT

    [ https://issues.apache.org/jira/browse/HDFS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738462#action_12738462

Konstantin Boudnik commented on HDFS-516:

Perhaps the common requirements aren't applicable to the contrib work, but I would like to
add few review comments:
- The content of TestSequenceFileSearcher.java is commented out. Should this file be included
in the patch at all?
- There's a push to upgrade existing test base to Junit4 (see HADOOP-4901 for more information).
I see that the tests are developed in old JUnit3 fashion (TestCase extension, lack of @Test
notation, junit.framework.* packages, etc.) Although JUnit4 will pickup these tests without
any problems, I'd suggest that new tests are compliant with JUnit4.
- a number of classes have a lack of JavaDocs even for public classes/methods
- the content of SequenceFileSearcher.java is commented out. Is it need to be a part of this
patch at all?
- pieces of the code here and there (e.g. ConcurrentLRUCache.java) are commented out. Should
they be just removed from the patch?
- some classes don't have standard Apache license boiler plate (ByteService.java, ByteServiceLazyInitializer.java,
and many other)
- FSDatasetInterface is being changed: shall this information be added to the release notes?

> Low Latency distributed reads
> -----------------------------
>                 Key: HDFS-516
>                 URL: https://issues.apache.org/jira/browse/HDFS-516
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>            Reporter: Jay Booth
>            Priority: Minor
>         Attachments: radfs.patch
>   Original Estimate: 168h
>  Remaining Estimate: 168h
> I created a method for low latency random reads using NIO on the server side and simulated
OS paging with LRU caching and lookahead on the client side.  Some applications could include
lucene searching (term->doc and doc->offset mappings are likely to be in local cache,
thus much faster than nutch's current FsDirectory impl and binary search through record files
(bytes at 1/2, 1/4, 1/8 marks are likely to be cached)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message