[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980454#action_12980454
]
Earwin Burrfoot commented on LUCENE-2793:
-----------------------------------------
{quote}
bq. You get IOFactory from Directory
That's for the default, the main use is the static IOFactory class.
{quote}
You lost me here. If you got A from B, you don't have to pass B again to invoke
A, if you do - that's 99% a design mistake.
But still, my point was that you don't need IOFactory at all.
bq. Right, however we're basically trying to intermix Directory's, which
doesn't work when pointed at the same underlying File. I thought about a
meta-Directory that routes based on the IOContext, however we'd still need a
way to create an IndexInput and IndexOutput, from different Directory
implementations.
What Directories are you trying to intermix? What for?
I thought the only thing done in that issue is an attempt to give Directory
hints as to why we're going to open its streams.
A simple enum IOContext and extra parameter on createOutput/Input would
suffice. But with Lucene's micromanagement attitude, an enum turns into
slightly more complex thing, with bufferSizes and whatnot.
Still - no need for mixing Directories.
> 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: Store
> Reporter: Michael McCandless
> Attachments: 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
