[
https://issues.apache.org/jira/browse/LUCENE-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418509#comment-13418509
]
Robert Muir commented on LUCENE-3659:
-------------------------------------
There is a patch somewhere to factor out the MMapIndexInput into a general
ByteBufferIndexInput if you follow the same rules.
I think we can just use that? you can have a direct and array-backed version
(just have some hook to allocate a new ByteBuffer of some size). I think we
should just start with the array-backed one for simplicity. Maybe the direct
one can avoid some arrays bounds checks, but otherwise its not really
related to the stupidity of current ramdirectory. arrays are fine, its just
they shouldnt be so tiny etc.
> Allow per-RAMFile buffer sizes based on IOContext and source of data (e.g.
> copy from another directory)
> -------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3659
> URL: https://issues.apache.org/jira/browse/LUCENE-3659
> Project: Lucene - Java
> Issue Type: Sub-task
> Affects Versions: 4.0-ALPHA
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.1
>
> Attachments: LUCENE-3659.patch, LUCENE-3659.patch, LUCENE-3659.patch
>
>
> Spinoff from several dev@lao issues:
> -
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/201112.mbox/%3C001001ccbf1c%2471845830%24548d0890%24%40thetaphi.de%3E]
> - issue LUCENE-3653
> The use cases for RAMDirectory are very limited and to prevent users from
> using it for e.g. loading a 50 Gigabyte index from a file on disk, we should
> improve the javadocs.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]