Thanks for the answer. That's what I was beginning to think based on the descriptions. I won't spend any more time on it. It's just another reason why eventually we'll move everything to Solr.
-----Original Message----- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Tuesday, November 06, 2012 5:32 AM To: java-user@lucene.apache.org Subject: Re: Near Real Time for multiple applications On Mon, Nov 5, 2012 at 6:33 PM, Scott Smith <ssm...@mainstreamdata.com> wrote: > I've been reading about NRT thinking it might be good to integrate it into my > code. However, I have a question. > > Suppose that the index writer and the index reader run in totally different > JVMs (i.e., they are different applications and only communicate via the > disk). Am I correct in thinking that NRT isn't going to do anything for me? That's correct: NRT is only usable if IndexReader/IndexWriter are in the same JVM. This is because we carry the deleted documents (bit vectors) in memory, passing them from writer to reader on reopen. We also don't write a new segments_N file. This is actually a limitation in Lucene's implementation: it would in theory be possible to write the deleted docs, write a segments file (but not fsync them, since it's not a commit), and then another JVM process with access to that same filesystem could do an ordinary reopen. It'd be slower than NRT is now, since deleted docs are going through the filesystem, and the reader would have to list the directory to see the new segments file, but would still be (typically) much faster than a commit... Mike --------------------------------------------------------------------- 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
