[ 
https://issues.apache.org/jira/browse/LUCENE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714983#action_12714983
 ] 

Uwe Schindler commented on LUCENE-1658:
---------------------------------------

bq. I think we should fix the test to make an exception...

I removed the test completely here, but forgot to include this into the patch. 
The test is now invalid with the new class hierarchy of FSDir. If FSDir gets 
abstract in 3.0, it is clear which methods need to be overridden and so on. The 
intention behind the test was, to check, if MMap does *not* overwrite all FSDir 
Methods, and because of this one of the calls could falsely return the standard 
FSDir impl of IndexInput. After Lucene 3.0, this is not possible, as MMapDir 
does not extend SimpleFSDir.

If we remove the test and then backwards-tag tests fail because of this, we 
could easily fix this by adding the method, simply calling super(). Or remove 
the test in backwards-tag, too.

{quote}
But: I think we shouldn't throw an exception if the hack fails? Ie, just 
fallback to relying on GC to eventually unmap? (What MMapDir does today).

And then we can make the default on Windows 64 be MMapDir again?

Also, can you reference this bug from FSDir's/MMapDir's javadocs?
{quote}

Good idea. The problem is, if the hack fails, IndexReader may suddenly fail 
later on windows to delete files. Or was this only a problem in the tests. What 
happens, if e.g. IndexWriter wants to write a new segments.gen file and so on, 
but it is still mmapped? So I preferred to throw the IOException, but I can 
disable this easily.

I would suggest to check on windows, if class sun.misc.Cleaner is available and 
if not, return SimpleFSDir. For Unix, it is enough to simply ignore the cleanup 
(throw no exception).


> 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: Uwe Schindler
>            Priority: Minor
>             Fix For: 2.9
>
>         Attachments: LUCENE-1658-take2.patch, LUCENE-1658-take2.patch, 
> LUCENE-1658-take3.patch, LUCENE-1658-take3.patch, LUCENE-1658-take3.patch, 
> LUCENE-1658-take3.patch, LUCENE-1658.patch, LUCENE-1658.patch, 
> 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

Reply via email to