[KinoSearch] Search in a clustered environment
mcrawfor at u.washington.edu
Thu Jan 18 15:48:08 PST 2007
>> 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
> 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?
KinoSearch mailing list
KinoSearch at rectangular.com
More information about the kinosearch