lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1658) Absorb NIOFSDirectory into FSDirectory
Date Mon, 01 Jun 2009 14:55:07 GMT

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

Michael McCandless commented on LUCENE-1658:
--------------------------------------------

Looks good -- thanks Uwe -- a few small things:


  * Can you remove the a/b from the LUCENE-1658 in CHANGES.txt?  (I
    think it may confuse the changes-to-html generation)

  * Can you point out that MMapDirectory will consume transient disk
    space, regardless of platform, because of this sun bug?  Ie, this
    bug is not just a "you can't delete the files on Windows"
    problem; it's a problem for unix as well.  Maybe something like
    this:
    .
    Due to <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038">this
bug</a>
    in Sun's JRE, MMapDirectory's IndexInput.close is unable to close
    the underlying OS file handle.  Only when GC finally collects the
    underlying objects, which could be quite some time later, will the file
    handle be closed.
    .
    This will consume additional transient disk usage: on Windows,
    attempts to delete or overwrite the files will result in an
    exception; on other platforms, which typically have a "delete on
    last close" semantics, while such operations will succeed, the bytes
    are still consuming space on disk.  For many applications this
    limitation is not a problem (eg if you have plenty of disk space,
    and you don't rely on overwriting files on Windows) but it's still
    an important limitation to be aware of.

  * Maybe don't make MMapDir.cleanUnmapping final, so subclasses could
    tweak it?  I'm still nervous about throwing IOException from that
    method if the unmap fails, but if we make it non-final then we can
    leave the IOException as is and users can subclass it if need be.

  * Can you embed the try/catch inside cleanMapping within { }'s?  The
    run-on (if -> try) is confusing now.



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


Mime
View raw message