lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Lea <>
Subject Re: Can I still use SearcherManager in this situation?
Date Wed, 07 Nov 2012 11:11:42 GMT
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()?


On Wed, Nov 7, 2012 at 4:08 AM, Trejkaz <> 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:
For additional commands, e-mail:

View raw message