m but didn't think it was related.
We are running 2.4.1
-Original Message-
From: "Ian Lea"
Sent: Thursday, September 10, 2009 5:05am
To: java-user@lucene.apache.org
Subject: Re: IndexReader.isCurrent for cached indexes
isCurrent() will only return true if there have been comm
e javadocs.
What version of lucene are you running?
--
Ian.
On Wed, Sep 9, 2009 at 10:33 PM, Nick Bailey
wrote:
> Looking for some help figuring out a problem with the IndexReader.isCurrent()
> method and cached indexes.
>
> We have a number of lucene indexes that we attempt to k
Looking for some help figuring out a problem with the IndexReader.isCurrent()
method and cached indexes.
We have a number of lucene indexes that we attempt to keep in memory after an
initial query is performed. In order to prevent the indexes from becoming
stale, we check for changes about
IndexReader.isCurrent() goes and opens that most recent segments_N
file from the index and then compares that version to its own. So if
your replication brought over a new segments_N then isCurrent would
return false.
Mike
rahul_k123 wrote:
I am doing replication and i am running
What do you mean by "manually"?
>
> Once an IndexWriter commits a change to the index after the
> IndexReader was opened, then IndexReader.isCurrent() will return false.
>
>> One more question
>>
>> The index is on Linux
>>
>> if my indexReader is
rahul_k123 wrote:
what is the behaviour of IndexReader.current() if i modify the index
manually? Will it returns false?
What do you mean by "manually"?
Once an IndexWriter commits a change to the index after the
IndexReader was opened, then IndexReader.isCurrent() will re
??
Any help is appreciated
Thanks
Rahul.
--
View this message in context:
http://www.nabble.com/IndexReader.isCurrent%28%29-tp19523435p19523435.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
-
To
t; Sent: Friday, May 11, 2007 11:03 AM
> To: java-user@lucene.apache.org
> Subject: Re: IndexReader.isCurrent very slow in 2.1
>
>
> : Are there are large number of files in your index directory?
>
> and is there any correlation between the number files matching segment*
>
igible, i.e.
less than 10 millis per call.
Thanks for your input.
Andreas
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 11:03 AM
To: java-user@lucene.apache.org
Subject: Re: IndexReader.isCurrent very slow in 2.1
: Are there are large num
"Andreas Guther" <[EMAIL PROTECTED]> wrote:
> I have optimized our index directories using the compound index format.
> I have also moved the index directories for testing purposes local to
> the search process (before it was over network and shared NTFS file
> system).
>
> Now the time for gett
.
less than 10 millis per call.
Thanks for your input.
Andreas
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 11:03 AM
To: java-user@lucene.apache.org
Subject: Re: IndexReader.isCurrent very slow in 2.1
: Are there are large number of
: I am experiencing a same problem with some 40 segments. Chris, Do you have
do you have 40 segments, or do you have 40 files matching the glob
segement* .. there is a differnece (the "segment" files records the number
of segments, as of 2.1 they are versioned so they have names like
"segments_7"
then will come back with more
information.
Andreas
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 11:03 AM
To: java-user@lucene.apache.org
Subject: Re: IndexReader.isCurrent very slow in 2.1
: Are there are large number of files in your
I am experiencing a same problem with some 40 segments. Chris, Do you have
any recommendation on the file system to use?
On 5/11/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Are there are large number of files in your index directory?
and is there any correlation between the number files
: Are there are large number of files in your index directory?
and is there any correlation between the number files matching segment*
and the time isCurrent taks?
it would also be handy to know what filesystem you use as well ...
directory listings may be more expensive on some filesystems then
"Andreas Guther" <[EMAIL PROTECTED]> wrote:
> I moved today from Lucene 2.0 to 2.1 and I noticed that the
> IndexReader.isCurrent() call is very expensive. What took 20
> milliseconds in 2.0 now takes seconds in 2.1.
>
> I have the following scenario:
>
&g
I moved today from Lucene 2.0 to 2.1 and I noticed that the
IndexReader.isCurrent() call is very expensive. What took 20
milliseconds in 2.0 now takes seconds in 2.1.
I have the following scenario:
- 7 index directories of different size, ranging from some MB to 5 GIG
- Some index are upgraded
17 matches
Mail list logo
