I've created https://issues.apache.org/jira/browse/LUCENE-5461, and attached a small test that shows the error it a setup similar to what I would like to run
The 1% is a overestimation - it seems to be related to concurrent commit on the index writer Hans Lund On Thu, Feb 20, 2014 at 2:04 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Thu, Feb 20, 2014 at 7:52 AM, Hans Lund <ha.l...@gmail.com> wrote: > > Ok, thats also what I expected, but not what I observed ;-) > > Ahh, not good. > > > For the very huge majority of index updates reopens are not an issue, > > minutes will be very fine. A very few updates are done 'interactively' > and > > must be in RT (or as close as possible). > > That's precisely the use case this class is designed for. I tried to > describe it here: > > http://blog.mikemccandless.com/2011/11/near-real-time-readers-with-lucenes.html > > (We've since renamed NRTManager -> ControlledRTReopenThread). > > > I don't know if this is a rare use case - but we don't expect the rate of > > specific generations request to be more than max a very few pr. > > minute/hour, we do not have any reason to "pile up" generation request > > behind a minStaleSec - as there will only be the one request in the end > > anyway. Therefore I have tried to set the minStaleSec to 0. Unfortunately > > this do not work as I expected as waitforgeneration() now blocks up to > > maxStaleTime (in about 1% of the time). > > That's not right. > > > If this is not the expected behavior I'll open an issue on it? > > For now I've handled it by calling maybeRefreshBlocking() when needed > from > > outside the reopener thread - but i hate the reflection needed to read > the > > searchingGen ;-.) > > Please open an issue! > > Mike McCandless > > http://blog.mikemccandless.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
