[KinoSearch] Possible Locking Improvements

[Chris Nandor]

At 14:00 -0800 2007.01.23, Marvin Humphrey wrote:
>A similar strategy can help us with the NFS problem.  We need the
>Searcher to set a read lock which the InvIndexer will recognize, so
>that it will spare any files that the Searcher still needs.

We do not enable NFS writes, only reads (which is why Slashdot is able to
reliably use NFS for its heavy load :-).  So I don't think that will work,
if I understand you correctly.  I suppose we could use MySQL as a proxy of
some sort, if we can subclass and put in our own method for
creating/reading the lockfile.

Another thing I keep tossing around is having a KinoSearch Server, which
would solve this problem by bypassing it.  :-)


>As a final note, I don't plan on coding this up before 0.20.  The
>people who are paying me to put it out don't need this feature.
>However, this is a popular request and I figured I'd get the concept
>out there.

Our existing method in Slash is to eval{} the call to Searcher->search, and
get a new searcher object if it fails.  (Same thing with a call to
IndexReader->num_docs.)  It works well enough for now, and we want a better
fix, but it is less important to us than the new features.

-- 
Chris Nandor                      pudge at pobox.com    http://pudge.net/
Open Source Technology Group       pudge at ostg.com     http://ostg.com/

_______________________________________________
KinoSearch mailing list
KinoSearch at rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch