[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980740#action_12980740
]
Robert Muir commented on LUCENE-2793:
-------------------------------------
{quote}
I'm perfectly OK with that approach (having some module FSDir checks). I also
feel uneasy having JNI in core.
What I don't want to see, is Directory impls that you can't use on their own.
If you can only use it for merging, then it's not a Directory, it breaks the
contract! - move the code elsewhere.
{quote}
Right, i think we all agree we want to fix the DirectIOLinuxDirectory into
being a 'real' directory?
As i said before, from a practical perspective, it could be named
LinuxDirectory, extend NIOFS,
and when openInput(IOContext=Merge) it opens its special input. but personally
i don't care how
we actually implement it 'becoming a real directory'. this is another issue,
unrelated to this one really.
this issue is enough and should stand on its own... we should be able to do
enough nice things
here without dealing with JNI: improving our existing directory impls to use
larger buffer sizes by
default when merging, etc (like in your example).
> 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
