You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2013/03/18 09:12:15 UTC

[jira] [Assigned] (LUCENE-4848) Add Directory implementations using NIO2 APIs

     [ https://issues.apache.org/jira/browse/LUCENE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler reassigned LUCENE-4848:
-------------------------------------

    Assignee: Uwe Schindler

Hi Michael,
thank you very much for the directory implementations.

I already thought about that a while before, but I was not aware, that the WindowsFileChannelFactory (http://www.docjar.com/html/api/sun/nio/fs/WindowsChannelFactory.java.html) automatically passes FILE_SHARE_DELETE by default to the windows open syscall. So this is indeed an improvement, because it allows to delete files that are opened like that. I have not yet verified this, but I trust you and will take it under consideration. But be warned: FILE_SHARE_DELETE does *not* completely emulate delete-after-last-close semantics from POSIX. It looks like the file keeps valid and disappears from the directory, but in contrast to POSIX, you cannot delete the directory the file is in, nor can you create a new file with the same name as the still open, but deleted one. This should not be an issue for Lucene, as it never recreates files with the same name which it keept open before.

About your classes in general. The *new* directory implementation (the Async one), could go into Lucene 5.0, once we moved to Java 7, so this would be a start in the direction on doing the move. We had a discussion on the mailinglist and all committers +1.

About the NIOFSDirectory and MMapDirectory: Those are 100% clones of the originals and we dont want to have 100% clones of same classes in Lucene core, so I would restructure them. The good thing here is: The really only change in those clones is the part that opens a FileChannel from a file name. And that involves only 3 calls to Java 7 APIs. My idea was to simply insert that code (using reflection for Lucene 4.x into the original MMapDirectory and NIOFSDirectory) into a helper function for opening (File in, FileChannel out) that creates a RAF on Java 6 and directly allocates FileChannel on Java 7 - Problem solved. Introducting new Java 7 symbols like "Path" into Lucene makes no sense at the moment, so its hidden as implementation detail.

I will provide a patch for NIOFS and MMap later.

Thanks in any case, this issue brought me to the right track of maybe solving the delete on windows problem - I am still not sure if this really helps and does not break the semantics Lucene expects from the underlying FS.
                
> Add Directory implementations using NIO2 APIs
> ---------------------------------------------
>
>                 Key: LUCENE-4848
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4848
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Michael Poindexter
>            Assignee: Uwe Schindler
>            Priority: Minor
>         Attachments: jdk7directory.zip
>
>
> I have implemented 3 Directory subclasses using NIO2 API's (available on JDK7).  These may be suitable for inclusion in a Lucene contrib module.
> See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5 for more details about this code and the advantages it provides.
> The code is attached as a zip to this issue.  I'll be happy to make any changes requested.  I've included some minimal smoke tests, but any help in how to use the normal Lucene tests to perform more thorough testing would be appreciated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org