Re: Lucene shouldn't use java.io.tmpdir

On Monday 12 July 2004 09:04, Morus Walter wrote: Lucene might work around this by creating a directory in java.io.tmpdir setting apropriate permission (can that be done with java os independently?) and put the lock there. But if everybody can delete your lock files, that would be a security

AW: Understanding TooManyClauses-Exception and Query-RAM-size

Hi Kevin, thanks for your answer. That could really solve the problem with the modificationDate or similar fields. But what if you create queries that ultimately return only a few hits but contain a RangeQuery that searches for example an ID-Field of some kind, where you have to cover a wide

Lucene Search has poor cpu utilization on a 4-CPU machine

Hi all, First let me explain what I found out. I'm running Lucene on a 4 CPU server. While doing some stress tests I've noticed (by doing full thread dump) that searching threads are blocked on the method: public FieldInfo fieldInfo(int fieldNumber) This causes for a significant cpu idle time. I

Re: AW: Understanding TooManyClauses-Exception and Query-RAM-size

[EMAIL PROTECTED] wrote: What I really would like to see are some best practices or some advice from some users who are working with really large indices how they handle this situation, or why they don't have to care about it or maybe why I am completely missing the point ;-)) Many folks with

Anyone use MultiSearcher class

Hello, Has anyone used the Multisearcher class? I have noticed that searching two indexes using this MultiSearcher class takes 8 times longer than searching only one index. I could understand if it took 3 to 4 times longer to search due to sorting the two search results and stuff, but why 8

Re: Lucene Search has poor cpu utilization on a 4-CPU machine

Aviran wrote: First let me explain what I found out. I'm running Lucene on a 4 CPU server. While doing some stress tests I've noticed (by doing full thread dump) that searching threads are blocked on the method: public FieldInfo fieldInfo(int fieldNumber) This causes for a significant cpu idle

Re:Anyone use MultiSearcher class

I think there is a ParallelMultiSearcher class that extands Multisearcher. Have you tried it? -- Debut du message initial --- De : Don Vaillancourt [EMAIL PROTECTED] A : Lucene Users List [EMAIL PROTECTED] Copies : Date : Mon, 12 Jul 2004 12:36:29 -0400 Sujet :

Re:Anyone use MultiSearcher class

Actually, after I implemented the MultiSeacher, I had totally forgotten about this class. Although it isn't clear what I does. I'm assuming that it uses threads to search multiple indexes. I'll have to try it. Thanks At 01:10 PM 12/07/2004, you wrote: I think there is a ParallelMultiSearcher

Re: Anyone use MultiSearcher class

Hi Don, Yes, I'm using the MultiSearcher (in Zilverline), and have seen no serious performance issues with it. The app performs well with multiple indexes, it's responds so quick (with 100k+ documents) that I haven't even taken the time to measure the difference to a single index search.

Re: Lucene Search has poor cpu utilization on a 4-CPU machine

Aviran wrote: I use Lucene 1.4 final Here is the thread dump for one blocked thread (If you want a full thread dump for all threads I can do that too) Thanks. I think I get the point. I recently removed a synchronization point higher in the stack, so that now this one shows up! Whether or not

Re: Browse by Letter within a Category

On Monday 12 July 2004 17:48, O'Hare, Thomas wrote: Does Lucene have a beginning of line query syntax, like the regular expression ^ symbol? For example, title:^A* If your title isn't tokenized the ^ is implicit, I think. As usual, if your title is tokenized you can easily add another

Exact match search

Hi, I want to match documents that exactly equal a certain value, not just contain it. If I search for foo in Lucene I get back documents like these: foo foo bar bar foo Is there a way to just get the ones that exactly equal the value I'm searching for? In this case, I want to only

Re: Exact match search

On Monday 12 July 2004 21:17, [EMAIL PROTECTED] wrote: I want to match documents that exactly equal a certain value, not just contain it. Just don't tokenize your Fields, and make sure that the query also doesn't get tokenized (the easiest way to ensure that is probably to not use

Re: Could search results give an idea of which field matched

See the explain functionality in the Javadocs and previous threads. You can ask Lucene to explain why it got the results it did for a give hit. [EMAIL PROTECTED] 07/12/04 04:52PM I search the index on multiple fields. Could the search results also tell me which field matched so that the

Re: Field.java - STORED, NOT_STORED, etc...

Doug Cutting wrote: It would be best to get the compiler to check the order. If we change this, why not use type-safe enumerations: http://www.javapractices.com/Topic1.cjp The calls would look like: new Field(name, value, Stored.YES, Indexed.NO, Tokenized.YES); Stored could be implemented as the

Re: Why is Field.java final?

Doug Cutting wrote: Kevin A. Burton wrote: I was going to create a new IDField class which just calls super( name, value, false, true, false) but noticed I was prevented because Field.java is final? You don't need to subclass to do this, just a static method somewhere. Why is this? I can't see

Re: Lucene Search has poor cpu utilization on a 4-CPU machine

Aviran wrote: Bug 30058 posted Which of course is here: http://issues.apache.org/bugzilla/show_bug.cgi?id=30058 Is this the source of the revision you modified? http://www.mail-archive.com/[EMAIL PROTECTED]/msg06116.html Also what version of Lucene? Kevin -- Please reply using PGP.