On Tue, Apr 05, 2005 at 08:16:35AM -0700, Otis Gospodnetic wrote:
> If you take this approach, keep in mind that you will also need to
> handle regular application shutdowns, and also try to catch some
> crashes/errors, in order to flush your in-memory queue of items
> scheduled for indexing, and w
Otis Gospodnetic wrote:
If you take this approach, keep in mind that you will also need to
handle regular application shutdowns, and also try to catch some
crashes/errors, in order to flush your in-memory queue of items
scheduled for indexing, and write them to disk.
Feel free to post the code, if
If you take this approach, keep in mind that you will also need to
handle regular application shutdowns, and also try to catch some
crashes/errors, in order to flush your in-memory queue of items
scheduled for indexing, and write them to disk.
Feel free to post the code, if you want and can, so pe
Hi,
we are using a very cautious method for batch upating.
We have long (hours) running updates on our index, but
complete reindexing would even be longer (days). But I
guess our strategy could be scaled down to hours or even
less.
So what we do is, we keep two instances
of the index. There is
e.org
Subject: Re: Strategies for updating indexes.
Hi,
please see comments below.
On Tue, Apr 05, 2005 at 08:38:04AM +0100, Lee Turner wrote:
> Hi
>
> I was wondering whether anyone has any experience of multithreaded
> updates to indexes. I the web app I am working on there are additio
Hi,
please see comments below.
On Tue, Apr 05, 2005 at 08:38:04AM +0100, Lee Turner wrote:
> Hi
>
> I was wondering whether anyone has any experience of multithreaded
> updates to indexes. I the web app I am working on there are additions,
> updates and deletes that need to happen to the index t
