throwing out wild guesses because I don't really see any
> problems in what you shared. Also - if the problem really has something to
> do with ControlledRealTimeReopenThread, I'm not going to have the answer, so
> I apologize but I think I need to bow out.
>
>
>
Yes that all looks reasonable. Maybe there is a mismatch in the
analysis chain? I'm just throwing out wild guesses because I don't
really see any problems in what you shared. Also - if the problem
really has something to do with ControlledRealTimeReopenThread, I'm not
go
; I am trying to do this with code based on
> http://stackoverflow.com/questions/17993960/lucene-4-4-0-new-controlledrealtimereopenthread-sample-usage.
> Automatically copying data from the master database to the index seems to
> work.
> However, removing items from the index not pres
ying to do this with code based on
http://stackoverflow.com/questions/17993960/lucene-4-4-0-new-controlledrealtimereopenthread-sample-usage.
Automatically copying data from the master database to the index seems to work.
However, removing items from the index not present in the database does not
se
trying to do this with code based on
http://stackoverflow.com/questions/17993960/lucene-4-4-0-new-controlledrealtimereopenthread-sample-usage.
Automatically copying data from the master database to the index seems to work.
However, removing items from the index not present in the database does not
seem
Time Manager
> (org.apache.lucene.search.NRTManager) has been replaced by
> ControlledRealTimeReopenThread. But as per Java doc it appears
> "experimenter".
>
> Please advise should I use ControlledRealTimeReopenThread as described at
> http://stackoverflow
Hi,
I am implementing NRT and looking for best practice to implement it. I
found that 4.4.0 release onwards the Near Real Time Manager
(org.apache.lucene.search.NRTManager) has been replaced by
ControlledRealTimeReopenThread. But as per Java doc it appears
"experimenter".
Please advis
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, M
On Thu, Feb 20, 2014 at 7:52 AM, Hans Lund 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
t;
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> 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
> rega
then LiveFieldValues might be useful.
Mike McCandless
http://blog.mikemccandless.com
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
&g
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 tim
12 matches
Mail list logo
