Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <15526125.1243250625966.JavaMail.jira@brutus>
Date: Mon, 25 May 2009 04:23:45 -0700 (PDT)
From: "Earwin Burrfoot (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1658) Absorb NIOFSDirectory into
 FSDirectory
In-Reply-To: <1868008588.1243181445652.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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