Insuffient resources during optimize merge

java:205) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(Concurr entMergeScheduler.java:260) Thanks Carl Austin This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of inte

RE: Insuffient resources during optimize merge

know what OS you are on, and versions of lucene and java. As a workaround you could perhaps try not using the compound file format. -- Ian. On Fri, Jul 3, 2009 at 11:12 AM, Carl Austin wrote: > Hi, > > I have an issue when optimizing a large index (40GB). Basically the > optimiz

RE: Insuffient resources during optimize merge

- Ian. On Fri, Jul 3, 2009 at 11:12 AM, Carl Austin wrote: > Hi, > > I have an issue when optimizing a large index (40GB). Basically the > optimize falls over with an IOException stating there are not enough > system resources, within a RandomAccessFile.readBytes call fol

MatchAllDocsQuery concurrency issue

Hi, I have been seeing an issue running MatchAllDocsQueries concurrently. Running one against a test index is very fast (70 ms). Running two concurrently can take 5-25 seconds on the same test index! This issue doesn't occur with any other type of query I have used. Because of this, I have put tog

RE: MatchAllDocsQuery concurrency issue

java-user@lucene.apache.org Subject: Re: MatchAllDocsQuery concurrency issue Most likely you're hitting this issue: https://issues.apache.org/jira/browse/LUCENE-1316 Which is fixed in 2.9. Can you try running with 2.9 to confirm? Mike On Thu, Aug 6, 2009 at 8:19 AM, Carl Austin wrote: &

RE: MatchAllDocsQuery concurrency issue

...@mikemccandless.com] Sent: 06 August 2009 13:52 To: java-user@lucene.apache.org Subject: Re: MatchAllDocsQuery concurrency issue Opening your IndexReader with readOnly=true should also fix it, I think. Mike On Thu, Aug 6, 2009 at 8:41 AM, Carl Austin wrote: > Thanks Mike, > > Running this

RE: Is there a way for me to handle a multiword synonym correctly?

I may be over simplifying here but in this case don't you just need to use an analyzer that breaks the word "SAP.EM.FIN.AM" on full stops and throws them out, so that it is indexed as terms "SAP" "EM" "FIN" "AM". This is the same as it will index "SAP EM FIN AM" as long as you break on whitespace t

FieldCache and 2.9

Hi, I have been using the FieldCache in lucene version 2.9 compared to that in 2.4. The load time is massively decreased, however I am not seeing any benefit in getting a field cache after re-open of an index reader when I have only added a few extra documents. A small test class is included below

RE: FieldCache and 2.9

entry must be created. Lucene 2.9 sorting requests FieldCache entries at the segment level and hence reuses entries for those segments that haven't changed. -Yonik Apache Lucene Eurocon 2010 18-21 May 2010 | Prague On Tue, May 11, 2010 at 9:27 AM, Carl Austin wrote: > Hi, > &g

RE: About the lucene sort

Don't prefix queries get rewritten wrapped in ConstantScoreQuery, meaning all will get the same score and you get them in read order? Checking the API, PrefixQuery uses MultiTermQuery.CONSTANT_SCORE_AUTO_REWRITE_DEFAULT, which can be changed with setRewriteMethod. -Original Message- From: