[KinoSearch] Search in a clustered environment

[Miles Crawford]

>> Perhaps if deleting the lock file was exposed via the API, the calling 
>> application could make the decision to nuke it if needed?  That might be 
>> exposing too much of KS's internals though.
>
> For now, it's going to stay private.  There's a huge amount of pressure on me 
> to get 0.20 out the door, and I'm not adding a public API for the locking 
> mechanism to my short-term todo list.

That sounds reasonable.  Long-term progress over short-term quick-fixery is a 
good policy.


> I'm open to suggestions about how the docs can be improved so that less 
> reading is required.  By disposition I favor minimal APIs with minimal 
> documentation and enjoy throttling feeping creatures.  However, it's hard for 
> me to understand how you would have made that assumption after even a passing 
> glance over the docs for SearchServer.  :(

The docs are fine - the first glance I gave them told me I was mistaken, I 
heard about the client/server for the first time from your email.


> I recommend maintaining two copies of the index on the NFS volume as 
> described in KinoSearch::Docs::NFS.  Use rync or equivalent rather than 
> copying because not all files change.

Granted about rsync, yeah.  But as for the scheme described in 
KinoSearch::Docs::NFS, I'm less certain.  I can't think of a particularly 
clean way of causing all the machines in my cluster to alternate the location 
of the index on a potentially very frequent cue.  I'd have to be flipping some 
flag in a database or managing an indication file on the NFS mount or 
something else relatively orthogonal to searching. At that point I have a 
process that seems overly complex and error-prone.

Sounds like your telling me that rsyncing the completed index over the old one 
is error-prone as well, huh?

-Miles

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