lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1658) Absorb NIOFSDirectory into FSDirectory
Date Mon, 25 May 2009 11:23:45 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message