[
https://issues.apache.org/jira/browse/LUCENE-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035357#comment-13035357
]
Robert Muir commented on LUCENE-3092:
-------------------------------------
{quote}
Tests? It's nice to have a test use a RAMDirectory for speed, but still follow
the same code path as FSDirectory for debugging + orthogonality.
{quote}
FWIW currently the lucene tests use a RAMDirectory 90% of the time (and
something else the other 10%).
We could adjust this... at the time I set it, it seemed to not slow the tests
down that much but
still give us a little more coverage.
> NRTCachingDirectory, to buffer small segments in a RAMDir
> ---------------------------------------------------------
>
> Key: LUCENE-3092
> URL: https://issues.apache.org/jira/browse/LUCENE-3092
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/store
> Reporter: Michael McCandless
> Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3092-listener.patch, LUCENE-3092.patch,
> LUCENE-3092.patch, LUCENE-3092.patch, LUCENE-3092.patch
>
>
> I created this simply Directory impl, whose goal is reduce IO
> contention in a frequent reopen NRT use case.
> The idea is, when reopening quickly, but not indexing that much
> content, you wind up with many small files created with time, that can
> possibly stress the IO system eg if merges, searching are also
> fighting for IO.
> So, NRTCachingDirectory puts these newly created files into a RAMDir,
> and only when they are merged into a too-large segment, does it then
> write-through to the real (delegate) directory.
> This lets you spend some RAM to reduce I0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
