When your app gets a java.lang.OutOfMemory exception.
--
Ian.
On 3/14/07, Dennis Berger [EMAIL PROTECTED] wrote:
Ian Lea schrieb:
No, you don't need 1.8Gb of memory. Start with default and raise if
you need to?
how do I know when I need it?
Or jump straight in at about 512Mb.
--
Ian
For what it's worth, Blackwell's uses Lucene for biblio searching.
Developed with the help of Lucene In Action.
--
Ian.
On 6/6/06, digby [EMAIL PROTECTED] wrote:
Thanks everyone, although now I'm not sure what to! Blackwells quicker
but more expensive, but is a new edition due...???
Think
http://lucene.apache.org/java/docs/api/org/apache/lucene/search/Searcher.html#search(org.apache.lucene.search.Query,%20org.apache.lucene.search.Sort)
http://www.lucenebook.com/search?query=sort
--
Ian.
[EMAIL PROTECTED]
On 21/09/05, Wi [EMAIL PROTECTED] wrote:
I want to sort results by some
In my experience, searching a read only index mounted via NFS is fine.
The NFS related issues are with locking.
I'd agree with Chris that you should try to avoid very big indexes.
--
Ian.
On 04/08/05, Chris Lu [EMAIL PROTECTED] wrote:
A big index is slow to merge, slow to search, and as you
= QueryParser.parse(line, keywords, analyzer);
you can see Eric's suggestion implemented in commented line.
am I doing something wrong here ? please let me know.
thanks and regards
Rahul Thakare..
On Tue, 19 Jul 2005 Ian Lea wrote :
Have you tried Erik's suggestion from last
Eric's suggestion implemented in commented line.
am I doing something wrong here ? please let me know.
thanks and regards
Rahul Thakare..
On Tue, 19 Jul 2005 Ian Lea wrote :
Have you tried Erik's suggestion from last week?
http://mail-archives.apache.org/mod_mbox/lucene
Have you tried Erik's suggestion from last week?
http://mail-archives.apache.org/mod_mbox/lucene-java-user/200507.mbox/[EMAIL
PROTECTED]
There is certainly some case confusion in your examples there.
Personally, I tend to just lowercase all text on indexing and
searching.
--
Ian.
On 19 Jul
Something like this?
IndexWriter iw = whatever
ResultSet rs = whatever
while (rs.next()) {
Document ldoc = new Document();
ldoc.add(Field.Text(f1, rs.getString(f1));
ldoc.add(Field.Unstored(f2, rs.getString(f2));
ldoc.add(Field.Keyword(f3, rs.getString(f3));
...
Sounds to me that all you need is to AND rather than OR your search terms.
QueryParser qp = new QueryParser(keywords, analyzer);
qp.setOperator(QueryParser.DEFAULT_OPERATOR_AND);
Query q = qp.parse(words);
where analyzer is just the standard one.
Or search for +MAIN
Might be interesting to know if it crashed on 2 docs if you ran it
with heap size of 512Mb. I guess you've already tried with default
merge values. Shouldn't need to optimize after every 100 docs. jdk
1.3 is pretty ancient - can you use 1.5?
I'd try it with a larger heap size, and then
http://lucene.apache.org/java/docs/api/org/apache/lucene/store/Lock.With.html#run()
--
Ian.
On 29/06/05, jian chen [EMAIL PROTECTED] wrote:
Hi,
I am looking at and trying to understand more about Lucene's
reader/writer synchronization. Does anyone know when the commit.lock
is release? I
901 - 911 of 911 matches
Mail list logo
