[
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: [email protected]
For additional commands, e-mail: [email protected]
