[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045322#comment-13045322
]
Simon Willnauer commented on LUCENE-2793:
-----------------------------------------
Very very quick review:
* I think OneMerge should not be required for createing a IOContext we maybe
should add a default ctor.
* IOContext.Other is confusing I think. If a IOContext doesn't make lots of
sense somewhere we should not need to pass it in. Can't we simply have
overloaded methods? maybe I just don't like the name, maybe use DEFAULT?
* IOContext seem to pretty straight forward you either read or write but it
seems to be confused with high level operations like Merge and Flush. Either
with go on a high level or we only have read and write here. Since read / write
is implicit (you either pull input or output) we should make this high-level
only. So maybe we have Query or Search instead of Read here? Maybe it makes
sense to specify stuff like Consume or Sequential here too some high level APIs
define sequential access so I think it does not conflict?
> 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: Varun Thacker
> Labels: gsoc2011, lucene-gsoc-11, mentor
> Attachments: LUCENE-2793.patch, LUCENE-2793.patch, 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
