lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: Patch - IndexReader methods and MultiSearcher methods...
Date Thu, 24 Feb 2005 23:11:28 GMT
Kevin A. Burton wrote:
>> Also, I assume that the reason you make the reader field protected is 
>> because getReader() is not sufficient, i.e., you want to set the 
>> reader.  This would stylistically be better done with a setReader() 
>> method, no?  Do you only change it at construction, or at runtime?  If 
>> you only change it at construction, then super(reader) in the 
>> constructor might suffice.
> We change it at runtime.  This is a ReloadableIndexSearcher that I 
> developed that can reload if an index has been optimized() or added to 
> by another external process.  I just have my external process do the 
> merger and then call reload() on the main index.  The cool thing about 
> this approach is that the entire webapp is operational while this 
> happens.  While the swap is happening searches just backup for a second 
> and then complete.  It also doesn't require 2x memory because I can 
> dispose of the current reader, block searches, then open the new reader.

That can easily be done without subclassing IndexSearcher.

   public class SearcherCache {
     private Searcher searcher;
     public synchronized Searcher getSearcher() { return searcher; }
     public synchronized setSearcher(Searcher searcher) {
       this.searcher = searcher;

Then use SearcherCache.getSearcher() whenever you need a searcher.  You 
could make it more complicated, e.g., have it automatically update the 
searcher when the index has changed, etc.  But none of that requires or 
is in particular faciliated by subclassing IndexSearcher, so far as I 
can see.

> Why don't we do this.  I don't think we should have a setReader then.  
> This way there's no strong contract that developers preserve things that 
> might break caching.  I'd like to keep the protected change though.  

Making the field protected is just an obscure way of making it 
changeable.  If we really need to make it settable, then we should add a 
setReader() method and add some cautions to its documentation.  But I'm 
not yet convinced this needs to be settable.


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

View raw message