First of all, thanks to all the people who helped me in getting the lucene
replication setup working and right now its live in our production :-)
Everything working fine, except that i am seeing some exceptions on slaves.
The following is the one which is occuring more often on slaves
at java
According to
https://issues.apache.org/jira/browse/LUCENE-1282?focusedCommentId=12596949#action_12596949
(Sun hotspot compiler bug in 1.6.0_04/05 affects Lucene), a workaround
for the bug which causes the CorruptIndexException was put in to the
2.3 branch and 2.4.
However, we are still experiencin
On Thu, Sep 25, 2008 at 5:04 PM, David Lee <[EMAIL PROTECTED]> wrote:
> thanks! So it seems like lucene does a sequential read of both terms
> information in the index and then skips around using docid iterators? Is it
> able to push the skipping around into the index so it doesn't need to read
> a
thanks! So it seems like lucene does a sequential read of both terms
information in the index and then skips around using docid iterators? Is it
able to push the skipping around into the index so it doesn't need to read
as much?
On Thu, Sep 25, 2008 at 10:56 AM, Yonik Seeley <[EMAIL PROTECTED]> wr
On Thu, Sep 25, 2008 at 1:39 PM, David Lee <[EMAIL PROTECTED]> wrote:
> I was wondering when lucene queries two or more terms, does that mean the
> time it takes will be twice as long? For example if I search +lucene
> +apache, then does lucene get all the documents that match 'lucene' and all
> th
Hi,
I was wondering when lucene queries two or more terms, does that mean the
time it takes will be twice as long? For example if I search +lucene
+apache, then does lucene get all the documents that match 'lucene' and all
the documents that match 'apache', and then combine them together? Or can it
Eran Sevi wrote:
I'm using Windows and it worked just fine, although the procedure is
a bit
awkward. Why do I have to open a new writer? closing the current one
(after
switching readers) isn't enough? is it because of deleted documents
that
need to be updated?
It's because Windows doesn'
Hi,
I just created the second release candidate for Lucene 2.4, here:
http://people.apache.org/~mikemccand/staging-area/lucene2.4rc2
These are the fixes since RC1:
* Issues with CheckIndex (LUCENE-1402)
* Removed new yet deprecated ctors for IndexWriter, and set
autoCommit=false de
simon litwan wrote:
hi all
i tried to reuse the IndexSearcher among all of the threads that are
doing searches as described in
(http://wiki.apache.org/lucene-java/LuceneFAQ#head-48921635adf2c968f7936dc07d51dfb40d638b82)
this works fine. but our application does continuous indexing. so the
Thanks Mike,
I'm using Windows and it worked just fine, although the procedure is a bit
awkward. Why do I have to open a new writer? closing the current one (after
switching readers) isn't enough? is it because of deleted documents that
need to be updated?
Do you know if it's different in more ad
Are you on Windows?
If so, you'll need to then open & close a new IndexWriter after the
old reader has switched to the optimized index. That will delete the
old files.
On other OSs, which usually implement "delete on last close", the disk
space should be automatically freed up once you
Hi,
I have the following scenario using Lucene 2.1
1. Open reader on index to perform some searches.
2. Use reader to check if index is optimized.
2. Open writer and run optimize()
3. Close old reader and open a new reader for further searches.
I expected that after closing the old reader , the
hi all
i tried to reuse the IndexSearcher among all of the threads that are
doing searches as described in
(http://wiki.apache.org/lucene-java/LuceneFAQ#head-48921635adf2c968f7936dc07d51dfb40d638b82)
this works fine. but our application does continuous indexing. so the
index is changing and
13 matches
Mail list logo
