lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1658) Absorb NIOFSDirectory into FSDirectory
Date Sun, 31 May 2009 11:06:07 GMT

    [ 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message