I just apdated to lucene 1.9.1 and when I use the method of
IndexWriter writer.setMergeFactor(1000) instead of the property
writer.mergeFactor=1000 breaks lucene completely...
any clue?
Emerson Cargnin
-
To unsubscribe,
I try 2 way for get count results:
1)
Query q =
IndexSearcher is =
int count = Is.search(q).length();
2)
Query q =
IndexSearcher is =
CountCollector collector = new CountCollector();
Is.search(q, collector);
Int count = collector.getCount();
First way return results for
my fault, the eclipse project I was running had a project reference
that was still pointing to the old version of lucene.
sorry for that :)
Emerson
On 10/03/06, emerson cargnin [EMAIL PROTECTED] wrote:
I just apdated to lucene 1.9.1 and when I use the method of
IndexWriter
this is in continuation of a previous email i sent
i have a 6gb index containing over 12 million terms.
looking at the Lucene code RAMDirectory.java
i see an int cast of the index file size, meaning there is a 2GB limit
did i miss something?
has anyone loaded more
I'm curious, how many documents in your index and what kind of
queries are you issuing? Even 1.6 seconds is a LONG time for a
search in most Lucene indexes.
Erik
On Mar 10, 2006, at 5:38 AM, Anton Potehin wrote:
I try 2 way for get count results:
1)
Query q =
Hi Erik and Otis
Do you think release a new LIA edition for lucene 2.0?
Regards
Ernesto.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index size: 3,6G, about 550 documents.
Each document contains 22 fields.
For search use:
int count
public void search() {
String query = ...
.
String[] mainFields = new String[]{name, keywords,
description};
HashMap required = new
I look forward for it also.
I even first look forward for LuceneInAction book to get up to date with
lucene 2.0.
Regards,
Jelda
-Original Message-
From: Ernesto De Santis [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 2:49 PM
To: Lucene Users List
Subject: Lucene In Action
Forget ;-) I use 32-bit platform (Fedora Core release 3), 1 GB RAM,
Celeron 2.40GHz.
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 4:33 PM
To: java-user@lucene.apache.org
Subject: Re: speed
Importance: High
I'm curious, how many
Hi,
You are opening IndexSearcher for each and every search request, which is
not adviasable.
Cache IndexSearcher or IndexReader.. This will surely improve your speed .
Greetings,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006
[EMAIL PROTECTED] wrote:
When I make search I get count = 37.
May be I do something not correctly?
I assume you are ran both variants repeatedly, in the same process (start
up costs etc)?
-
To unsubscribe, e-mail:
This code is example ;-) I already use cache ;-)
-Original Message-
From: Ramana Jelda [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 5:15 PM
To: java-user@lucene.apache.org
Subject: RE: speed
Importance: High
Hi,
You are opening IndexSearcher for each and every search
Each variant started in different process
-Original Message-
From: Eric Jain [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 5:15 PM
To: java-user@lucene.apache.org
Subject: Re: speed
Importance: High
[EMAIL PROTECTED] wrote:
When I make search I get count = 37.
May be
Sorry. I was repeated test. And now both way have same speed.
-Original Message-
From: Anton Potehin [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 1:39 PM
To: java-user@lucene.apache.org
Subject: speed
Importance: High
I try 2 way for get count results:
1)
Query q =
But I think that 1.7 sec for the reception of simply number of results much
slowly (index 3,6G).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 5:40 PM
To: java-user@lucene.apache.org
Subject: RE: speed
Importance: High
Sorry. I was
Otis and I certainly appreciate the interest! And I have been
spending some time recently contemplating this effort. A 2nd edition
of a book is perhaps the most painful thing to contemplate, even more
so than a root canal. With both of us busier than we ever have been,
it is a challenge
thanks Yonik, did not notice that. I patched my code not to run the
search in that case, previous versions of lucene did not throw any
exception in the same case though.
thanks
On 3/10/06, Yonik Seeley [EMAIL PROTECTED] wrote:
Hi Javier,
The exception is happening on the last line of this
Is there a technique, using Lucene, to retrieve the remaining index
values from the results of a query?
Here is a better explanation of the question.
I have various fields that have been indexed on a particular
collection of Java POJO's. For example, an Employee object may have
the following
3. Use the ThreadLocal's FieldReader in the document() method.
As I understand it, this means that the document method no longer needs to
be synchronized, right?
I've made these changes and it does appear to improve performance. Random
snapshots of the stack traces show only an occasional lock
Peter,
I think this is similar to the patch in this bugzilla task:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35838
the patch itself is http://issues.apache.org/bugzilla/attachment.cgi?id=15757
(BTW does JIRA have a way to display the patch diffs?)
The above patch also has a change to
I have already implemented in my application using annotations.
and some changes to query input in my application.
How has it worked out for you?
I don't see where you provide Analyzer annotation. It seems u forgot it.
Not forgotten (though it could make a good addition); the intention is
Hi all,
I was reading one of the posting on concurrency and I reread section 9.1 in
Lucene in Action which lead me to this question. I have 100,000 customers and I
want to provide them with personal searching for their documents and sometimes
to include company documents in that search.
1.
22 matches
Mail list logo