lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Smith <>
Subject RE: Near Real Time for multiple applications
Date Wed, 07 Nov 2012 18:17:16 GMT
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 [] 
Sent: Tuesday, November 06, 2012 5:32 AM
Subject: Re: Near Real Time for multiple applications

On Mon, Nov 5, 2012 at 6:33 PM, Scott Smith <> 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...


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

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

View raw message