[ 
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980546#action_12980546
 ] 

Jason Rutherglen commented on LUCENE-2793:
------------------------------------------

bq. The directory is the factory for opening the correct openInput/createOutput 
based on its parameters, this just needs to be one.

Right, however which Directory impl is going to do this?  Today they're tied to 
their specific implementations of IndexInputs and IndexOutputs, eg, 
NIOFSIndexInput, DirectIOLinuxIndexInput, etc.  In order to get an 
NIOFSIndexInput we need to instantiate NIOFSDirectory, however if we also want 
to use DirectIOLinuxDirectory, then (in today's model) we need to instantiate 
it as well.  To create an index or output, all we need is a parent FSDIrectory 
and the rest is encapsulated in the underlying input/output implementation.  

> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to