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
isCurrent() will only return true if there have been committed changes
to the index. Maybe for some reason your index update job hasn't
committed or closed the index.
Probably not relevant to this problem, but your reopen code snippet
doesn't close the old reader. It should. See the javadocs.
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 scr
I am doing replication and i am running scripts to sync the index b/w master
and slave.
Michael McCandless-2 wrote:
>
>
> 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"?
>
>
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 return false.
One
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:
>
> - 7 index directories of different size
14 matches
Mail list logo
