[
https://issues.apache.org/jira/browse/LUCENE-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033520#comment-13033520
]
Robert Muir commented on LUCENE-3092:
-------------------------------------
just an idea: with issues like this that work (but hackishly) and are self
contained, I'm
not sure we should block them on some huge refactoring like IOContext if they
are actually usable
Of course I had this same opinion on LUCENE-2829, and gave up there, but I like
the idea
of adding things that have a little hackishness (but work) to our 3.x branch,
especially
if they can be experimental or contribs, and then refactoring for elegance in
trunk.
I don't think users should have to wait until 4.0 for features because we won't
add them until we
totally refactor the world... its ok to add them hackishly in 3.x if we are
"fixing" the larger issues in trunk.
As far as scariness factor, is is really worse than forcefully unmapping direct
byte buffers with sun.* methods in MMapDirectory?!
> 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: Store
> Reporter: Michael McCandless
> Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3092-listener.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
