lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mcmoi...@comcast.net
Subject Re: IndexSearcher cache
Date Mon, 05 Mar 2007 23:29:08 GMT
I agree those are benefits when you batch process the indexes once or once in a while.

The beauty of AOP is that I can intercept writes and do change the index on the spot. At that
point I'd need to let the search know or drop it. If I do that that will face issues on the
search side since this should be a thread safe environment . It's possible that while some
one tries to search the IndexSearcher will be dropper or not yet fully initialized... I tried
to create a seacher everytime but that lead me to the Too-Many-Files-Open exception. So no
matter what I do I face a show stopper. 


 -------------- Original message ----------------------
From: Doron Cohen <DORONC@il.ibm.com>
> 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
> 
> mcmoisei@comcast.net 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" <erickerickson@gmail.com>
> > > <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 <mnrz57@gmail.com> 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: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message