Author: creamyg
Date: 2007-03-15 09:08:36 -0700 (Thu, 15 Mar 2007)
New Revision: 2178
Removed:
trunk/perl/lib/KinoSearch/Docs/NFS.pod
Log:
Remove NFS.pod -- with the addition of LockFactory and IndexReader to the
public API, it no longer applies.
Deleted: trunk/perl/lib/KinoSearch/Docs/NFS.pod
===================================================================
--- trunk/perl/lib/KinoSearch/Docs/NFS.pod 2007-03-15 08:13:29 UTC (rev 2177)
+++ trunk/perl/lib/KinoSearch/Docs/NFS.pod 2007-03-15 16:08:36 UTC (rev 2178)
@@ -1,73 +0,0 @@
-=head1 NAME
-
-KinoSearch::Docs::NFS - Managing invindexes on NFS.
-
-=head1 Problem
-
-When a file is no longer in use by an index, InvIndexer attempts to delete it
-as part of a cleanup routine triggered by a call to finish(). It is possible
-that at the moment an InvIndexer attempts to delete files that it no longer
-thinks are needed, a Searcher is in fact using them. This is particularly
-likely in a persistent environment (mod_perl, FastCGI, etc), where Searchers
-are cached and reused. Ordinarily, this is not a problem.
-
-On a typical Unix volume, the file will be deleted in name only: any process
-which holds an open filehandle against that file will continue to have access,
-and the file won't actually get vaporized until the last filehandle is
-cleared. Thanks to "delete on last close semantics", an InvIndexer can't
-truly delete the file out from underneath an active Searcher.
-
-On Windows, KinoSearch will attempt the file deletion, but an error will occur
-if any process holds an open handle. That's fine; InvIndexer runs these
-unlink() calls within an eval block, and if the attempt fails it will just try
-again the next time around.
-
-On NFS, however, the system breaks, because NFS allows files to be deleted out
-from underneath an active process. Should this happen, the unlucky Searcher
-will crash with a "Stale NFS Filehandle" exception.
-
-=head1 Workaround
-
-The workaround is to maintain multiple copies of an index.
-
-=over
-
-=item 1
-
-Start state: Two identical indexes, A and B. Searchers are active against A.
-
-=item 2
-
-An InvIndexer updates B. As it finishes, it deletes any unneeded files.
-
-=item 3
-
-Searchers are switched to using index B.
-
-=item 4
-
-Synchronize index A so that it looks exactly the same as B. You could just
-delete A and copy B onto where it was, but there are more efficient ways of
-handling the synchronization since not all the files change -- e.g. rsync,
-pax.
-
-=item 5
-
-An InvIndexer updates A. As it finishes, it deletes any unused files.
-
-=item 6
-
-Etc...
-
-=back
-
-=head1 COPYRIGHT
-
-Copyright 2005-2007 Marvin Humphrey
-
-=head1 LICENSE, DISCLAIMER, BUGS, etc.
-
-See L<KinoSearch> version 0.20.
-
-=cut
-
Date: 2007-03-15 09:08:36 -0700 (Thu, 15 Mar 2007)
New Revision: 2178
Removed:
trunk/perl/lib/KinoSearch/Docs/NFS.pod
Log:
Remove NFS.pod -- with the addition of LockFactory and IndexReader to the
public API, it no longer applies.
Deleted: trunk/perl/lib/KinoSearch/Docs/NFS.pod
===================================================================
--- trunk/perl/lib/KinoSearch/Docs/NFS.pod 2007-03-15 08:13:29 UTC (rev 2177)
+++ trunk/perl/lib/KinoSearch/Docs/NFS.pod 2007-03-15 16:08:36 UTC (rev 2178)
@@ -1,73 +0,0 @@
-=head1 NAME
-
-KinoSearch::Docs::NFS - Managing invindexes on NFS.
-
-=head1 Problem
-
-When a file is no longer in use by an index, InvIndexer attempts to delete it
-as part of a cleanup routine triggered by a call to finish(). It is possible
-that at the moment an InvIndexer attempts to delete files that it no longer
-thinks are needed, a Searcher is in fact using them. This is particularly
-likely in a persistent environment (mod_perl, FastCGI, etc), where Searchers
-are cached and reused. Ordinarily, this is not a problem.
-
-On a typical Unix volume, the file will be deleted in name only: any process
-which holds an open filehandle against that file will continue to have access,
-and the file won't actually get vaporized until the last filehandle is
-cleared. Thanks to "delete on last close semantics", an InvIndexer can't
-truly delete the file out from underneath an active Searcher.
-
-On Windows, KinoSearch will attempt the file deletion, but an error will occur
-if any process holds an open handle. That's fine; InvIndexer runs these
-unlink() calls within an eval block, and if the attempt fails it will just try
-again the next time around.
-
-On NFS, however, the system breaks, because NFS allows files to be deleted out
-from underneath an active process. Should this happen, the unlucky Searcher
-will crash with a "Stale NFS Filehandle" exception.
-
-=head1 Workaround
-
-The workaround is to maintain multiple copies of an index.
-
-=over
-
-=item 1
-
-Start state: Two identical indexes, A and B. Searchers are active against A.
-
-=item 2
-
-An InvIndexer updates B. As it finishes, it deletes any unneeded files.
-
-=item 3
-
-Searchers are switched to using index B.
-
-=item 4
-
-Synchronize index A so that it looks exactly the same as B. You could just
-delete A and copy B onto where it was, but there are more efficient ways of
-handling the synchronization since not all the files change -- e.g. rsync,
-pax.
-
-=item 5
-
-An InvIndexer updates A. As it finishes, it deletes any unused files.
-
-=item 6
-
-Etc...
-
-=back
-
-=head1 COPYRIGHT
-
-Copyright 2005-2007 Marvin Humphrey
-
-=head1 LICENSE, DISCLAIMER, BUGS, etc.
-
-See L<KinoSearch> version 0.20.
-
-=cut
-