[
https://issues.apache.org/jira/browse/LUCENE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712696#action_12712696
]
Earwin Burrfoot commented on LUCENE-1658:
-----------------------------------------
bq. Excellent point - I think that makes sense. I'll fold it in as well.
Doesn't make sense to me. :/ MMapD has different characteristics. It can also
have it's own configurable properties, which are irrelevant for NIOFSD and FSD.
For example, my version of MMapD uses MappedByteBuffer.load() on creating
MMapIndexInput. That way the cost of loading stuff into memory is paid upfront
on reopening the reader, instead of during first several searches.
If we want to publish this feature into trunk, we'll end up with additional
parameter on MMapD constructor, that governs whether we want to preload mmapped
files, or not.
Now imagine constructor for FSD-that-folds-it-all, which has 'type', and a
boolean setting that's relevant only for one of the types.
I also think of trying to use mmap for writing. If that proves to be
beneficial, MMapD won't share much with FSD anymore.
In the end, I'm unsure if it's a good idea to fold anything into FSD at all.
Too much different stuff in one class becons for spahetti code :) I assume your
initial aim is to provide users with best impl for current platform without
making them think. What about static factory that chooses between several
impls? We had static factory before, it stinked because you had to chose impl
through system property, it pooled directories and we had no public
constructors. But now we have public constructors :) If one needs, he uses
constructor directly. If one is lazy and wants us to choose for him he uses old
API, that simply changes semantics a bit.
> Absorb NIOFSDirectory into FSDirectory
> --------------------------------------
>
> Key: LUCENE-1658
> URL: https://issues.apache.org/jira/browse/LUCENE-1658
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1658.patch
>
>
> I think whether one uses java.io.* vs java.nio.* or eventually
> java.nio2.*, or some other means, is an under-the-hood implementation
> detail of FSDirectory and doesn't merit a whole separate class.
> I think FSDirectory should be the core class one uses when one's index
> is in the filesystem.
> So, I'd like to deprecate NIOFSDirectory, absorbing it into
> FSDirectory, and add a setting "useNIO" to FSDirectory. It should
> default to "true" for non-Windows OSs, because it gives far better
> concurrent performance on all platforms but Windows (due to known Sun
> JRE issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734).
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
