lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: IndexSearcher cache
Date Mon, 05 Mar 2007 23:37:14 GMT
My two cents:

Lucene often offers the least common denominator...for example: out of 
the box, Lucene best handles either a single user / single thread 
experience or a mostly 'read only' experience. I believe that the main 
reason for this is that it serves the greatest variety uses. You can, 
and people have, put a layer on top of Lucene's simple abstractions to 
handle a very interactive index that must serve many threads.

One of your best options is Solr. Solr (among many, many other things) 
handles opening and closing Readers and Searchers for you in order to 
maintain a lively index. Throw in all of the caching, distribution, and 
schema options and its hard to argue that you shouldn't always use this 
for a multi user interactive index.

Another option is:

I don't think this option has gotten the attention it deserves. If you 
are not interested in Solr, or your requirements are not quite as steep, 
390 is a great tool. 390 will correctly manage Directories, Readers, 
Writers, and Searchers in a way that allows any index modifications to 
trigger the reopening of Readers. Making sure there is only one Writer 
and so forth is handled for you. There are a lot of enhancements you can 
make to this cool little issue and it is also very easy to integrate 
into a current solution.

- Mark

Doron Cohen wrote:
> Indeed, having to re-open a searcher/reader in order for searches
> to reflect index modification, can sometimes not best fit with the
> logic of a certain application.
> But see the features made possible with this design:
> (+) searches do not feel index modifications until desired.
> (++) no need to synchronize/interfere between searchers and index updates.
> (+++) stable non-corruptable index without duplicating index data.
> Doron
> wrote on 05/03/2007 11:02:34:
>> That part is self understood. However as I describe the problem
>> initially - and the use case is a very practical way of dealing with
>> documents in real live - they change, we edit them, I don't want to
>> run a batch re-indexing thing every night... I just wanted done on
>> the spot. One instance IndexerSeacher it's the way to go I today
>> agree but because it's reader doesn't detect the changes in the
>> files because is not being used to do them it's pretty anoying don't
>> you all thing ?
>>  -------------- Original message ----------------------
>> From: "Erick Erickson" <>
>>> <1>. Every time you close/open a reader, you pay a significant penalty
>>> to warm up caches, etc. You may have to do some tricky dancing
>>> to coordinate among the sessions to be able to close/reopen
>>> the reader to allow updates to show up though.
>>> Erick
>>> On 3/5/07, Mohammad Norouzi <> wrote:
>>>> Hi Erick
>>>> I am completely confused about this IndexReader.
>>>> in my case, I have to keep the reader opened because of pagination of
> the
>>>> result so I have to had a reader per session. the thing that baffled
> me is
>>>> can only one reader service all the session at the same time?
>>>> I mean
>>>> 1- having one reader for all sessions and having a Hits for each
> session.
>>>> 2- one reader per session.
>>>> which one is right?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message