lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: NRT indexing and ControlledRealTimeReopenThread
Date Thu, 20 Feb 2014 11:12:26 GMT
It is intended that there are two different stale times.

When a specific generation is requested, we wait for the minStaleSec
since the last reopen; this is to prevent too-frequent reopens when
specific gens are requested.

The maxStaleSec is how long we wait between reopens for the "normal"
periodic reopens, when the incoming request does not need a specific

This approach is only effective if most searches can just use the
current searcher, i.e. most searches do not need a specific
generation.  If you truly need "real-time" values for nearly all
searches then LiveFieldValues might be useful.

Mike McCandless

On Thu, Feb 20, 2014 at 4:37 AM, Hans Lund <> wrote:
> Hi all
> I'm a bit unsure about the intended function of
> the ControlledRealTimeReopenThread in a NRT context - especially regarding
> stale times.
> As of now if you are waiting for a generation to become refreshed, it looks
> like the stale time is either the min stale time or the max stale time. Is
> this the intended behavior?
> What i'm really looking for is 2 stale times with a slightly different
> semantics. a stale time for refreshing when no specific generation is
> needed, and another stale time for blocking acquiring of the blocked
> searcher, (well the last time can actually be avoided all together as I
> can't see any usage for a blocking acquiring should actually sleep at all
> It would be better to run the SearchManager.maybeRefreshBlocking(); in the
> thread needing the searcher @ a current generation.
> Cheers

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

View raw message