[KinoSearch] Possible Locking Improvements

[Chris Nandor]

At 15:01 -0800 2007.01.23, Marvin Humphrey wrote:
>Have a look, see what you think: <http://issues.apache.org/jira/
>browse/LUCENE-710>

I like to keep things simple, so I like the notion of "keep last N days'
worth."  Heck, for our purposes in this particular project, we want to
refresh our searcher object once a minute or so anyway.  So days could be
hours, or minutes.

Although I do like the notion of snapshots, in this particular project,
while there will be pagination, we also want the updates to happen fluidly
and reflect the current state of affairs.  So we'd opt for most recent
index, rather than an older snapshot, whenever possible.  If that makes
sense.

Right now we just have a timeout, but I can also see the code looking at
the index timestamp to see if it needs to refresh the searcher object.  On
the other hand, when we later do a more general content search, having
snapshots might be nice.  Something to think about, anyway.

And the more I think about this, the more I think eventually we will want a
Search Server anyway.  The expensiveness of a Searcher object (bloating our
httpd processes), the hassles with NFS, the problems of keeping the
Searcher as up-to-date as possible, and so on ... it just screams out to a
Search Server solution, I think.  (And it would be simple to code up, too,
though we'd need to dedicate HW to it, I think, so it's not something I'd
want to just do now.)

Not that I mind trying to work on this problem a little, even if we don't
end up using the solution.  I still don't know what we will end up doing
anyway.  :-)

-- 
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