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
