lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson" <>
Subject Re: IndexSearcher - architecture - shortest possible latency between update of index (via IndexWriter/IndexReader) and querying the same using IndexSearcher
Date Thu, 08 Jan 2009 18:10:36 GMT
This topic has been discussed *very* extensively, so I'd recommend you
search the mail archive (see )
since there are more good ideas there than I can remember. But the short
answer is that you must open a new searcher for modifications to be seen.

There are schemes for real-time updating, (see the archive) but they all
take work. There are no out-of-the-box solutions that I know of.

I don't understand your last paragraph at all.


On Thu, Jan 8, 2009 at 12:27 PM, Kay Kay <> wrote:

> Hi-
>  For one of our apps - we are doing a lot of additions and deletions (high
> frequency) at any given time.  Assuming the same index directory under
> discussion between the  writers ( IndexWriter and IndexReader, the latter
> for deletions) and the readers (IndexSearcher to begin with) - we want the
> IndexSearcher to retrieve the most updated index at the shortest possible
> time (with more priority on the most updated data).  So when a IndexWriter
> and IndexReader updates a particular index directory (with proper locking
> between themselves) and when we search using IndexSearcher (that could have
> been initialized / warmed up in the past )- will another search query
> initiated from the same IndexSearcher instance consider the updated index in
> real time.
>  Are the IndexSearcher instances  'watching' the index directories for
> changes and updating their data structures internally.
>  What would be the best / fastest way to make sure that IndexSearcher
> instances return data that are semantically data ( assuming the sequential
> order of data). What are the trade-offs that we can make here - when it
> comes to design decisions of a Lucene-based application. Thanks.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message