Hi Klaus, If you've really still got 500MB of changes to your index since the last time you commit()'ed, then the call to commit() will be costly and take a while to complete. If in another thread, you reopen() an IndexReader pointing to that index, it will only see changes since the most recently *completed* commit. Just as it can be costly to commit() after too small of a batch size (making many small segments and requiring frequent merges), making too infrequent commit()'s is costly from the standpoint of searcher visibility of changes.
If you want faster turnaround from addDocument() to query visibility, using the Lucene 2.9 IndexWriter.getReader() method can speed things up in this regard, but this method hasn't been tested under heavy (rapid) indexing and query loads as of yet. Another alternative for realtime searching is to use Zoie (Apache licensed realtime search built on top of lucene: http://zoie.googlecode.com ), which we use at LinkedIn for immediate searcher visibility to documents added under high throughput and heavy query load. -jake On Fri, Sep 25, 2009 at 10:41 AM, Klaus Teller <klaus.tel...@gmx.net> wrote: > Hi, > > I've read that it is possible to update the index while another thread has > a reader open. > > Now let's say the reader is trying to reopen the index (using its reopen > method) and at the very same time, the write its committing its 500MB > changes to the index. My question is, what happens in this situation? What > index does the reader end up having if it tries to open the index while the > writer is modifying it? > > Any feedback will be much appreciated, > > Klaus. > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 > - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
