Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CALUM-yscMYTxKO7hJSEHYY16mEkT3FXByju1=eRUFLp+nU8esg@mail.gmail.com>
References: 
 <CALUM-yscMYTxKO7hJSEHYY16mEkT3FXByju1=eRUFLp+nU8esg@mail.gmail.com>
From: Michael McCandless <lucene@mikemccandless.com>
Date: Thu, 20 Feb 2014 06:12:26 -0500
Message-ID: 
 <CAL8Pwkambu5YUqK7z9Ct1dzxYkDa43WgEknCBgTu3iu034eQ1w@mail.gmail.com>
Subject: Re: NRT indexing and ControlledRealTimeReopenThread
To: Lucene Users <java-user@lucene.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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.lund@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org