[
https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609714#comment-13609714
]
Michael Poindexter commented on LUCENE-4864:
--------------------------------------------
bq. If this is only gonna help Windows 32 (ancient platform by now?) ... we
should limit its visibility somehow I think.
Perhaps you are right. I implemented this stuff because I am doing some
"interesting" things with directories, and the inability to delete open files
on Windows boxes was causing me some trouble. I really want to compare this
vs. NIOFS on Windows, since I'll probably end up using one of those because as
Uwe pointed out mmap'ing files prevents them from being deleted.
Seems like this might still be useful for anyone on Win 32, or does not want to
be reflecting into JRE core code to clean up buffers like MMap directory does
(I see why it does it, but I'm still a bit wary of doing something like this in
my app...my indexes are fairly small, and search is a small enough part of what
my app does that I'm willing to take a reasonable performance hit to avoid it).
> Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0
> only)
> -------------------------------------------------------------------------------
>
> Key: LUCENE-4864
> URL: https://issues.apache.org/jira/browse/LUCENE-4864
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/store
> Affects Versions: 5.0
> Reporter: Michael Poindexter
> Attachments: LUCENE-4864.patch, LUCENE-4864.patch
>
>
> On LUCENE-4848 a new directory implementation was proposed that uses
> AsyncFileChannel to make a sync-less directory implementation (only needed
> for IndexInput). The problem on Windows is that positional reads are
> impossible without overlapping (async) I/O, so FileChannel in the JDK has to
> syncronize all reads, because they consist of an atomic seek and atomic read.
> AsyncFSDirectoty would not have this issue, but has to take care of thread
> management, because you need a separate thread to get notified when the read
> is done. This involves overhead, but might still be better than the
> synchronization.
--
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]
