[
https://issues.apache.org/jira/browse/LUCENE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714853#action_12714853
]
Uwe Schindler commented on LUCENE-1658:
---------------------------------------
bq The original purpose of the cache was to ensure each unique directory in the
filesystem alway mapped to a single instance of FSDir, so that you could
synchronize on that instance and be certain that this is equivalent to
synchronizing access to that underlying filesystem directory.
In my opinion, the cached directories vs. instantiated directories have one big
advantage:
They are forced to use the same locking mechanism. So if somebody creates a
directory using one LockFactory, writes to the index and in a parallel thread
uses another locking mechanism with a separate dir instance, he corrupts his
index. So from that point of view, only have one directory instance per
resource is a good thing (it does not work from different JVM processes, sure).
bq. Ie, it's only if you use the new FSDir.open() API that you get the new
behavior. I intentionally went and fixed tests to use FSDir.open so that we
stress the new functionality, which then led us to discover tests making
invalid assumptions, which we should then fix.
This is correct. For unit testing, I found out now, that it is much simplier to
check, if all tests would also work with other platforms, if you set the FSDir
system property when running the tests. With open() this is currently not
possible.
Maybe I un-comment-out the caching again, but let getDirectory still use the
new behaviour, if the system property is not set. We could then in 3.0 just
remove the caching, but let getDirectory() alive. I am not sure.
In my opinion, this is not really a more serious bw-change than a small
behaviour change, that can be written into CHANGES.txt. We have more serious
ones.
I would strongly tend to remove the cache at all and write a warning into
CHANGES.txt.
At all, I do not really think anybody has implemented an own subclass of FSDir.
The current patch's bw-change is more, that the protected no-arg ctors no
longer exist and are no longer used.
> 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: [email protected]
For additional commands, e-mail: [email protected]
