[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041642#comment-13041642
]
Chris Male commented on LUCENE-2793:
------------------------------------
{quote}
So, if we really don't want to include these classes, and instead pick &
choose what "digested" properties to include... then we risk some Dir
impl not having access to something "interesting" because we forgot to
include it, which means they'll have to hack something up, like
NRTCachingDir does now in coupling threads to OneMerge instances.
But, maybe the restrictions won't be so bad in practice... if we can
try to brainstorm what Dirs may want to "know" about the full context
and include that in IOCtx.
{quote}
I think the alternatives to this are definitely worse. I've been trying to
think of some sort of intermediary component that could decouple the interests
of Directories from the sources of that info, but it just seems to make
everything way more complicated. I agree it seems best to stick to what Dirs
want to know, present that as the IOCtx, and then work out the sources of that
information.
> Directory createOutput and openInput should take an IOContext
> -------------------------------------------------------------
>
> Key: LUCENE-2793
> URL: https://issues.apache.org/jira/browse/LUCENE-2793
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/store
> Reporter: Michael McCandless
> Assignee: Simon Willnauer
> Labels: gsoc2011, lucene-gsoc-11, mentor
> Attachments: LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch,
> LUCENE-2793.patch
>
>
> Today for merging we pass down a larger readBufferSize than for searching
> because we get better performance.
> I think we should generalize this to a class (IOContext), which would hold
> the buffer size, but then could hold other flags like DIRECT (bypass OS's
> buffer cache), SEQUENTIAL, etc.
> Then, we can make the DirectIOLinuxDirectory fully usable because we would
> only use DIRECT/SEQUENTIAL during merging.
> This will require fixing how IW pools readers, so that a reader opened for
> merging is not then used for searching, and vice/versa. Really, it's only
> all the open file handles that need to be different -- we could in theory
> share del docs, norms, etc, if that were somehow possible.
--
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
