[
https://issues.apache.org/jira/browse/LUCENE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466117
]
Marvin Humphrey commented on LUCENE-710:
----------------------------------------
(This is a continuation of the discussion from one of the threads quoted in the
previous comment, with some summations to provide context.)
Referring to a proposal to implement advisory locking where possible, and
prevent index creation on volumes/systems where the delete mechanism fails,
Michael McCandless wrote:
But what I don't like about it is it doesn't "gracefully degrade" to
the common NFS case where locking does not work. And, this is often
outside our user's control.
The stratagem of publicly exposing IndexFileDeleter does not "degrade
gracefully", either.
If today's default deletions policy remains the default, then when an index is
put on an NFS system, at some point search-time exceptions will occur after an
update to an index. The user has to 1) detect this scenario without Lucene's
help, probably from logs or user complaints 2) diagnose it without the aid of a
meaningful error message, and 3) either implement their own IndexFileDeleter or
choose an appropriate provided subclass, a task which will require that they
grok both the innards of Lucene and the subtleties of NFS.
The first step to graceful degradation is a meaningful error message. That
means detecting a problem which normally requires both a indexing process and a
search process to trigger, so we have to simulate it artificially with a test.
1) Open a file for read/write and write a few bytes to it.
2) Delete the test file (without closing the handle).
3) Try to read from the handle and if a "stale NFS filehandle"
exception is caught, throw something more informative.
Our first opportunity to perform this test occurs at index-creation time. This
is essentially cost free.
A second opportunity arises whenever deletions are performed. Here, there's a
small cost involved, and it may not be worth it, as this would only catch cases
where an index was copied onto an NFS volume rather than created there, then
subsequently modified.
There's also another stratagem available to us: we can have IndexReaders
establish advisory read locks against their relevant segments_N files on
systems which support such locks. This won't help us to "degrade gracefully".
However, it will help us degrade less often, as modern versions of NFS support
file locking - but still do NOT support the "delete-on-last-close" mechanism
Lucene depends on.
Implementing advisory read locks is orthogonal to the addition of
IndexFileDeleter, but diminishes the justification for adding it as a public
API.
But the good news is since we will allow subclassing to make your own
deletion policy, we can eventually do both of these approaches and our
users can pick one or do their own.
The number of users this class will serve is diminishingly small. Other
mitigation strategies are available.
1) If we implement advisory read locks, many people who see this error will no
longer see it. For those who do, the best option is to upgrade the OS to a
version which supports advisory locks over NFS. Then an index on an NFS volume
will behave as any other.
2) If you don't actually need to put the index on an NFS volume, put it
somewhere else.
3) Catch stale NFS filehandle exceptions in your search application and refresh
the reader when they occur.
4) Maintain two copies of an index and do an rsync/switch.
5) Hack Lucene.
Flexibility is not free. There have been recent lamentations on java-dev about
how difficult it will be to merge the write interfaces of IndexReader and
IndexWriter to provide a single, unified class through which all index
modifications can be performed. The exposure of the IndexFileDeleter mechanism
contributes to this problem -- it's one more small step in the wrong direction.
Providing a subclassing/callback API is often an elegant strategy, and it is
surely better in this case than it would be to provide a list of deletion
policies for the user to select from. However, whenever possible, _no_ API is
always a better solution -- especially in a case like this one, where the
functionality provided has nothing to do with Lucene's core mission and is
there solely to work around an implmentation-specific bug.
> Implement "point in time" searching without relying on filesystem semantics
> ---------------------------------------------------------------------------
>
> Key: LUCENE-710
> URL: https://issues.apache.org/jira/browse/LUCENE-710
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
>
> This was touched on in recent discussion on dev list:
> http://www.gossamer-threads.com/lists/lucene/java-dev/41700#41700
> and then more recently on the user list:
> http://www.gossamer-threads.com/lists/lucene/java-user/42088
> Lucene's "point in time" searching currently relies on how the
> underlying storage handles deletion files that are held open for
> reading.
> This is highly variable across filesystems. For example, UNIX-like
> filesystems usually do "close on last delete", and Windows filesystem
> typically refuses to delete a file open for reading (so Lucene retries
> later). But NFS just removes the file out from under the reader, and
> for that reason "point in time" searching doesn't work on NFS
> (see LUCENE-673 ).
> With the lockless commits changes (LUCENE-701 ), it's quite simple to
> re-implement "point in time searching" so as to not rely on filesystem
> semantics: we can just keep more than the last segments_N file (as
> well as all files they reference).
> This is also in keeping with the design goal of "rely on as little as
> possible from the filesystem". EG with lockless we no longer re-use
> filenames (don't rely on filesystem cache being coherent) and we no
> longer use file renaming (because on Windows it can fails). This
> would be another step of not relying on semantics of "deleting open
> files". The less we require from filesystem the more portable Lucene
> will be!
> Where it gets interesting is what "policy" we would then use for
> removing segments_N files. The policy now is "remove all but the last
> one". I think we would keep this policy as the default. Then you
> could imagine other policies:
> * Keep past N day's worth
> * Keep the last N
> * Keep only those in active use by a reader somewhere (note: tricky
> how to reliably figure this out when readers have crashed, etc.)
> * Keep those "marked" as rollback points by some transaction, or
> marked explicitly as a "snaphshot".
> * Or, roll your own: the "policy" would be an interface or abstract
> class and you could make your own implementation.
> I think for this issue we could just create the framework
> (interface/abstract class for "policy" and invoke it from
> IndexFileDeleter) and then implement the current policy (delete all
> but most recent segments_N) as the default policy.
> In separate issue(s) we could then create the above more interesting
> policies.
> I think there are some important advantages to doing this:
> * "Point in time" searching would work on NFS (it doesn't now
> because NFS doesn't do "delete on last close"; see LUCENE-673 )
> and any other Directory implementations that don't work
> currently.
> * Transactional semantics become a possibility: you can set a
> snapshot, do a bunch of stuff to your index, and then rollback to
> the snapshot at a later time.
> * If a reader crashes or machine gets rebooted, etc, it could choose
> to re-open the snapshot it had previously been using, whereas now
> the reader must always switch to the last commit point.
> * Searchers could search the same snapshot for follow-on actions.
> Meaning, user does search, then next page, drill down (Solr),
> drill up, etc. These are each separate trips to the server and if
> searcher has been re-opened, user can get inconsistent results (=
> lost trust). But with, one series of search interactions could
> explicitly stay on the snapshot it had started with.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
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]
