OK I just committed it -- thanks! Mike
On Mon, Oct 12, 2009 at 5:01 PM, Jake Mannix <jake.man...@gmail.com> wrote: > That seems a lot more straightforward Mike, thanks. > > -jake > > On Mon, Oct 12, 2009 at 1:56 PM, Michael McCandless < > luc...@mikemccandless.com> wrote: > >> I agree, the javadocs could be improved. How about something like >> this for the first 2 paragraphs: >> >> * Returns a readonly reader, covering all committed as >> * well as un-committed changes to the index. This >> * provides "near real-time" searching, in that changes >> * made during an IndexWriter session can be quickly made >> * available for searching without closing the writer nor >> * calling {...@link #commit}. >> * >> * <p>Note that this is functionally equivalent to calling >> * {#commit} and then using {...@link IndexReader#open} to >> * open a new reader. But the turarnound time of this >> * method should be faster since it avoids the potentially >> * costly {...@link #commit}.<p> >> >> Mike >> >> On Mon, Oct 12, 2009 at 4:35 PM, Jake Mannix <jake.man...@gmail.com> >> wrote: >> > Thanks Yonik, >> > >> > It may be surprising, but in fact I have read that >> > javadoc. It talks about not needing to close the >> > writer, but doesn't specifically talk about the what >> > the relationship between commit() calls and >> > getReader() calls is. I suppose I should have >> > interpreted: >> > >> > "@returns a new reader which contains all >> > changes..." >> > >> > to mean "all uncommitted changes", but why >> > is it so obvious that what could be happening >> > is that it only "returns all changes since the last >> > commit, but without touching disk because it >> > has docs in memory as well"? >> > >> > -jake >> > >> > On Mon, Oct 12, 2009 at 1:26 PM, Yonik Seeley < >> yo...@lucidimagination.com>wrote: >> > >> >> Guys, please - you're not new at this... this is what JavaDoc is for: >> >> >> >> /** >> >> * Returns a readonly reader containing all >> >> * current updates. Flush is called automatically. This >> >> * provides "near real-time" searching, in that changes >> >> * made during an IndexWriter session can be made >> >> * available for searching without closing the writer. >> >> * >> >> * <p>It's near real-time because there is no hard >> >> * guarantee on how quickly you can get a new reader after >> >> * making changes with IndexWriter. You'll have to >> >> * experiment in your situation to determine if it's >> >> * fast enough. As this is a new and experimental >> >> * feature, please report back on your findings so we can >> >> * learn, improve and iterate.</p> >> >> * >> >> * <p>The resulting reader supports {...@link >> >> * IndexReader#reopen}, but that call will simply forward >> >> * back to this method (though this may change in the >> >> * future).</p> >> >> * >> >> * <p>The very first time this method is called, this >> >> * writer instance will make every effort to pool the >> >> * readers that it opens for doing merges, applying >> >> * deletes, etc. This means additional resources (RAM, >> >> * file descriptors, CPU time) will be consumed.</p> >> >> * >> >> * <p>For lower latency on reopening a reader, you should >> >> * call {...@link #setMergedSegmentWarmer} to >> >> * pre-warm a newly merged segment before it's committed >> >> * to the index. This is important for minimizing >> >> * index-to-search delay after a large merge. </p> >> >> * >> >> * <p>If an addIndexes* call is running in another thread, >> >> * then this reader will only search those segments from >> >> * the foreign index that have been successfully copied >> >> * over, so far</p>. >> >> * >> >> * <p><b>NOTE</b>: Once the writer is closed, any >> >> * outstanding readers may continue to be used. However, >> >> * if you attempt to reopen any of those readers, you'll >> >> * hit an {...@link AlreadyClosedException}.</p> >> >> * >> >> * <p><b>NOTE:</b> This API is experimental and might >> >> * change in incompatible ways in the next release.</p> >> >> * >> >> * @return IndexReader that covers entire index plus all >> >> * changes made so far by this IndexWriter instance >> >> * >> >> * @throws IOException >> >> */ >> >> public IndexReader getReader() throws IOException { >> >> >> >> >> >> -Yonik >> >> http://www.lucidimagination.com >> >> >> >> >> >> On Mon, Oct 12, 2009 at 4:18 PM, John Wang <john.w...@gmail.com> wrote: >> >> > Oh, that is really good to know! >> >> > Is this deterministic? e.g. as long as writer.addDocument() is called, >> >> next >> >> > getReader reflects the change? Does it work with deletes? e.g. >> >> > writer.deleteDocuments()? >> >> > Thanks Mike for clarifying! >> >> > >> >> > -John >> >> > >> >> > On Mon, Oct 12, 2009 at 12:11 PM, Michael McCandless < >> >> > luc...@mikemccandless.com> wrote: >> >> > >> >> >> Just to clarify: IndexWriter.newReader returns a reader that searches >> >> >> uncommitted changes as well. Ie, you need not call >> IndexWriter.commit >> >> >> to make the changes visible. >> >> >> >> >> >> However, if you're opening a reader the "normal" way >> >> >> (IndexReader.open) then it is necessary to first call >> >> >> IndexWriter.commit. >> >> >> >> >> >> Mike >> >> >> >> >> >> On Mon, Oct 12, 2009 at 5:24 AM, melix <cedric.champ...@lingway.com> >> >> >> wrote: >> >> >> > >> >> >> > Hi, >> >> >> > >> >> >> > I'm going to replace an old reader/writer synchronization mechanism >> we >> >> >> had >> >> >> > implemented with the new near realtime search facilities in Lucene >> >> 2.9. >> >> >> > However, it's still a bit unclear on how to efficiently do it. >> >> >> > >> >> >> > Is the following implementation the good way to do achieve it ? The >> >> >> context >> >> >> > is concurrent read/writes on an index : >> >> >> > >> >> >> > 1. create a Directory instance >> >> >> > 2. create a writer on this directory >> >> >> > 3. on each write request, add document to the writer >> >> >> > 4. on each read request, >> >> >> > a. use writer.getReader() to obtain an up-to-date reader >> >> >> > b. create an IndexSearcher with that reader >> >> >> > c. perform Query >> >> >> > d. close IndexSearcher >> >> >> > 5. on application close >> >> >> > a. close writer >> >> >> > b. close directory >> >> >> > >> >> >> > While this seems to be ok, I'm really wondering about the >> performance >> >> of >> >> >> > opening a searcher for each request. I could introduce some kind of >> >> delay >> >> >> > and cache a searcher for some seconds, but I'm not sure it's the >> best >> >> >> thing >> >> >> > to do. >> >> >> > >> >> >> > Thanks, >> >> >> > >> >> >> > Cedric >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > View this message in context: >> >> >> >> >> >> http://www.nabble.com/Realtime-search-best-practices-tp25852756p25852756.html >> >> >> > Sent from the Lucene - Java Users mailing list archive at >> Nabble.com. >> >> >> > >> >> >> > >> >> >> > >> --------------------------------------------------------------------- >> >> >> > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> >> >> > For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> >> > >> >> >> > >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> >> >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> >> >> >> >> >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org