On Tue, Oct 13, 2009 at 5:23 AM, Ganesh wrote:
> In case of 2.4.1, the reader after reopen, will be warmed before actual use.
You mean you must warm it after you call reopen, before using it, right?
> In 2.9, public void setMergedSegmentWarmer(IndexWriter.IndexReaderWarmer
> warmer), does warm
OK I opened https://issues.apache.org/jira/browse/LUCENE-1976.
Mike
On Tue, Oct 13, 2009 at 6:05 AM, Michael McCandless
wrote:
> I agree isCurrent doesn't work right for an NRT reader. Right now, it
> will always return "true" because it's sharing the segmentInfos in use
> by the writer.
>
> Si
I agree isCurrent doesn't work right for an NRT reader. Right now, it
will always return "true" because it's sharing the segmentInfos in use
by the writer.
Similarly, getVersion will lie.
I'll open an issue to track how to fix it.
Mike
On Mon, Oct 12, 2009 at 6:12 PM, Yonik Seeley
wrote:
> Go
performance?
Does warming necessarly required in 2.9? If we do warming for the very first
time is not enough? Do we need to do it on every request?
Regards
Ganesh
- Original Message -
From: "Yonik Seeley"
To:
Sent: Tuesday, October 13, 2009 3:42 AM
Subject: Re: Realtime s
Good point on isCurrent - I think it should only be with respect to
the latest index commit point? and we should clarify that in the
javadoc.
[...]
> // but what does the nrtReader say?
> // it does not have access to the most recent commit
> // state, as there's been a commit (with documents)
> /
wever, it's still a bit unclear on how to efficiently do it.
>> >> >
>> >> > Is the following implementation the good way to do achieve it ? The
>> >> context
>> >> > is concurrent read/writes on an index :
>> &g
melix
> >> >> wrote:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > I'm going to replace an old reader/writer synchronization mechanism
> we
> >> >> had
> >> >> > implemented with the
I think it was my email Yonik responded to and he is right, I was being lazy
and didn't read the javadoc very carefully.My bad.
Thanks for the javadoc change.
-John
On Mon, Oct 12, 2009 at 1:57 PM, Yonik Seeley wrote:
> On Mon, Oct 12, 2009 at 4:35 PM, Jake Mannix
> wrote:
> > It may be surpri
On Mon, Oct 12, 2009 at 1:57 PM, Yonik Seeley wrote:
> On Mon, Oct 12, 2009 at 4:35 PM, Jake Mannix
> wrote:
> > It may be surprising, but in fact I have read that
> > javadoc.
>
> It was not your email I responded to.
>
Sorry, my bad then - you said "guys" and John and I were the last two to b
n) then it is necessary to first call
>> >> >> IndexWriter.commit.
>> >> >>
>> >> >> Mike
>> >> >>
>> >> >> On Mon, Oct 12, 2009 at 5:24 AM, melix
>> >>
gt;> >> > I'm going to replace an old reader/writer synchronization mechanism
> we
> >> >> had
> >> >> > implemented with the new near realtime search facilities in Lucene
> >> 2.9.
>
On Mon, Oct 12, 2009 at 4:35 PM, Jake Mannix wrote:
> It may be surprising, but in fact I have read that
> javadoc.
It was not your email I responded to.
> It talks about not needing to close the
> writer, but doesn't specifically talk about the what
> the relationship between commit() calls a
gt; > However, it's still a bit unclear on how to efficiently do it.
>> >> >
>> >> > Is the following implementation the good way to do achieve it ? The
>> >> context
>> >> > is concurrent read/writes on an index :
>> >> &
and cache a searcher for some seconds, but I'm not sure it's the best thing
> to do.
>
> Thanks,
>
> Cedric
>
>
> --
> View this message in context:
> http://www.nabble.com/Realtime-search-best-practices-tp25852756p25852756.html
> Sent from the Lucene - Java User
> > 2. create a writer on this directory
> >> > 3. on each write request, add document to the writer
> >> > 4. on each read request,
> >> > a. use writer.getReader() to obtain an up-to-date reader
> >> > b. create an IndexSearcher with that reader
eader() to obtain an up-to-date reader
>> > b. create an IndexSearcher with that reader
>> > c. perform Query
>> > d. close IndexSearcher
>> > 5. on application close
>> > a. close writer
>> > b. close directory
>> >
>> &
each request. I could introduce some kind of delay
> > and cache a searcher for some seconds, but I'm not sure it's the best
> thing
> > to do.
> >
> > Thanks,
> >
> > Cedric
> >
> >
> > --
> > View this message
On Mon, Oct 12, 2009 at 12:26 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> On Mon, Oct 12, 2009 at 3:17 PM, Jake Mannix
> wrote:
>
> > Wait, so according to the javadocs, the IndexReader which you got from
> > the IndexWriter forwards calls to reopen() back to
> IndexWriter.getRea
On Mon, Oct 12, 2009 at 3:17 PM, Jake Mannix wrote:
> Wait, so according to the javadocs, the IndexReader which you got from
> the IndexWriter forwards calls to reopen() back to IndexWriter.getReader(),
> which means that if the user has a NRT reader, and the user keeps calling
> reopen() on it,
application close
> > a. close writer
> > b. close directory
> >
> > While this seems to be ok, I'm really wondering about the performance of
> > opening a searcher for each request. I could introduce some kind of delay
> > and cache a searcher for some seconds, b
be ok, I'm really wondering about the performance of
> opening a searcher for each request. I could introduce some kind of delay
> and cache a searcher for some seconds, but I'm not sure it's the best thing
> to do.
>
> Thanks,
>
> Cedric
>
>
> --
> View
not sure it's the best thing
> to do.
>
> Thanks,
>
> Cedric
>
>
> --
> View this message in context:
> http://www.nabble.com/Realtime-search-best-practices-tp25852756p25852756.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
&g
#x27;m not sure it's the best thing
to do.
Thanks,
Cedric
--
View this message in context:
http://www.nabble.com/Realtime-search-best-practices-tp25852756p25852756.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---
23 matches
Mail list logo
