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 generation. 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 http://blog.mikemccandless.com On Thu, Feb 20, 2014 at 4:37 AM, Hans Lund <ha.l...@gmail.com> 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: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org