[
https://issues.apache.org/jira/browse/CASSANDRA-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795749#action_12795749
]
Hudson commented on CASSANDRA-408:
----------------------------------
Integrated in Cassandra #310 (See
[http://hudson.zones.apache.org/hudson/job/Cassandra/310/])
productize mmap approach: handle files > 2GB by chunking w/ fallback to BRAF
when a row crosses chunk boundaries (you don't want to have to check for
crossing
boundary in each read() call, or you'll almost certainly waste more time than
the BRAF approach); add retrying-delete to wait for mmapped files to be unmapped
by finalizer after compaction
patch by jbellis; reviewed by Brandon Williams and goffinet for
Implement FileDataInput with MappedFileDataInput, backed by a mmap'd ByteBuffer.
patch by jbellis; reviewed by Brandon Williams and goffinet for
add FileDataInput, implemented by BufferedRandomAccessFile
patch by jbellis; reviewed by Brandon Williams and goffinet for
> Pool BufferedRandomAccessFile objects used by sstable reads
> -----------------------------------------------------------
>
> Key: CASSANDRA-408
> URL: https://issues.apache.org/jira/browse/CASSANDRA-408
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.9
>
> Attachments:
> 0001-add-FileDataInput-implemented-by-BufferedRandomAccessF.txt,
> 0002-Implement-FileDataInput-with-MappedFileDataInput-backe.txt,
> 0003-productize-mmap-approach-handle-files-2GB-by-chunking-.txt, 408.patch,
> commons-pool-1.5.2.jar
>
>
> not only does BRAF per op do a whole lot of extra fopens, but the buffering
> actually makes it _more_ expensive to set up since on the jvm all primitive
> arrays are initialized to zero.
> this adds a simple read test to stress.py; I'm seeing about a 10% increase in
> throughput which is worth 200loc imo.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
