4.0 has maybeRefreshBlocking which "is useful if you want to guarantee that the next call to acquire() will return a refreshed instance". You don't say what version you're using.
If you're stuck on 3.6.1 can you do something with refreshIfNeeded() or isSearcherCurrent()? -- Ian. On Wed, Nov 7, 2012 at 4:08 AM, Trejkaz <trej...@trypticon.org> wrote: > In our application, most users sit around in read-only mode all the time > but there is one place where write access can occur, which is essentially > scripted at the moment. (*) > > Currently, we start out opening an IndexReader. When the caller declares > that they are going to start writing, we open an IndexWriter. When they > finish writing, they declare that, at which point we close the IndexWriter > and reopen the IndexReader. > > NRTManager vaguely sounded like the thing for the job but since we don't > have an IndexWriter from the start, I guess it cannot be used (actually, at > the start, you don't even know if you have write access - and even if you > do, you shouldn't be locking the index unless you're really going to make > changes. Otherwise you will be depriving some other user of doing the > same...) > > Currently I'm looking at SearcherManager. It looks like the current API has > maybeRefresh(), which spins off a refresh in the background, but unlike > NRTManager, doesn't appear to have any way to wait for that refresh to > finish. Essentially I want to know when I can get a new IndexSearcher which > is up to date with my written changes. > > Is there some "right" way to do this? I hope I don't have to reimplement > some weird combination of SearcherManager and NRTManager myself. > > TX > > > (*) The larger case of writing bulk data to the index is done while the > index is not openable by the user, so it is excluded from the problem space > for now. Later it would be nice to do something about that as well, but > there are various problems. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
