[
https://issues.apache.org/jira/browse/LUCENE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714866#action_12714866
]
Uwe Schindler commented on LUCENE-1658:
---------------------------------------
bq. Yikes - you mean there's a pre-existing issue with the fix in LUCENE-1453,
before this issue was committed? I agree that code is very spooky, and I'll be
very happy once we remove (in 3.0) the cache/refCounting done by
FSDir.getDirectory....
The problem is not really the caching/refcounting. The reopen code sometimes
seems to close the directory, even than it should not. There is no difference
if the directory is cached (and the number of opens() is tracked by refCount)
or standalone. The problem is that SegmentReader's readNorms() hits
AlreadyClosedException then...
The interesting thing is that ou can more easy reproduce it with stand-alone
dirs (because I removed the caching, you know). The 1453 fix is also needed for
stand-alone dirs (so everytime codeDirectory=true), because, if they are closed
during an error/whatever, the same happens. It does not happen so easy with
cached dirs, because the old reader is normally closed after the new reopened
one, so during the reopen, the refcount is big enough.
In my opinion, the only good solution is to remove the whole directory-close
stuff from readers/writers in 3.0, as said before. And this can be done by
removing the string-type dir arguments from Reader/Writer. And: As these use
currently FSDir.getDirectory() they should be changed to FSDir.open() or
deprecated, I tend to the last one.
> 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.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
