[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980649#action_12980649
]
Earwin Burrfoot commented on LUCENE-2793:
-----------------------------------------
What's with ongoing crazyness? :)
bq. DirectIOLinuxDirectory
First you introduce a kind of directory that is utterly useless except certain
special situations. Then, instead of fixing the directory/folding its code
somewhere normal, you try to workaround by switching between directories.
What's the point of using abstract classes or interfaces, if you leak their
implementation's logic all over the place?
Or making DIOLD wrap something. Yeah! Wrap my RAMDir!
bq. bufferSize
This value is only meaningful to a certain subset of Directory implementations.
So the only logical place we want to see this value set - is these very impls.
Sample code:
{code}
Directory ramDir = new RAMDirectory();
ramDir.createIndexInput(name, context);
// See, ma? No bufferSizes, they are pointless for RAMDir
Directory fsDir = new NIOFSDirectory();
fsDir.setBufferSize(IOContext.NORMAL_READ, 1024);
fsDir.setBufferSize(IOContext.MERGE, 4096);
fsDir.createIndexInput(name, context)
// See, ma? The only one who's really concerned with 'actual' buffer size is
this concrete Directory impl
// All client code is only concerned with the context.
// It's NIOFSDirectory's business to give meaningful interpretation for
IOContext and assign the buffer sizes.
{code}
You don't need custom Directory impls to make DIOLD work, you should freakin'
fix it.
The proper way is to test out the things, and then move DirectIO code to the
only place it makes sense in - FSDir? Probably make it switch on/off-able,
maybe not.
You don't need custom Directory impls to set buffer sizes (neither cast to
BufferedIndexInput!), you should add the setting to these Directories, which
make sense of it.
> 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
