Re: running out of file handles

> Are you opening a new IndexSearcher when you see a new index version > (using IndexReader.getCurrentVersion())? If so, you may need to > explicitly call close() on your IndexSearcher before opening a new > one. no.. I'm not doing that.. but the index get's updated very seldom. Maybe 4 times a

Re: running out of file handles

Hi Guillermo, Are you opening a new IndexSearcher when you see a new index version (using IndexReader.getCurrentVersion())? If so, you may need to explicitly call close() on your IndexSearcher before opening a new one. Also note that IndexSearcher has 3 constructors. Two of them automatically c

Re: running out of file handles

oh.. sorry, I apologize.. I now realize I should have posted this to java-user list instead --G On Thu, Apr 14, 2005 at 09:12:41PM -0700, Guillermo Payet wrote: > Hi, > > We have one instance of IndexSearcher that's used for our entire > web application. It's instantiated from a bean

Re: UnscoredRangeQuery

Hi Yonik, I'm interested, but I didn't see any files attached. Not sure if it's at my end or the mailing list. Is there another way I can get these files? Thanks -Chris On 4/14/05, Yonik Seeley <[EMAIL PROTECTED]> wrote: > OK, so I implemented an UnscoredRangeQuery we needed for use with > l

UnscoredRangeQuery

OK, so I implemented an UnscoredRangeQuery we needed for use with lucene 1.4.3. Seems to work fine for me, so I thought I would put it out here to see what you guys think... (files attached) Would a cleaned up version be useful for some version of Lucene, or will all the current work that Paul is

RE: [Performance] Streaming main memory indexing of single strings

It is really not that involved. Just implement the abstract methods of IndexReader. And many cane be no-op'd because they will never be called in a "read only" situation. Methods related to normalization and such can also be no-op'd because you are only dealing with a single document. I would thi

Re: [Performance] Streaming main memory indexing of single strings

This seems to be a promising avenue worth exploring. My gutfeeling is that this could easily be 10-100 times faster. The drawback is that it requires a fair amount of understanding of intricate Lucene internals, pulling those pieces together and adapting them as required for the seemingly simpl

Re: Efficient Sorting of Hits/Results Using an Encoded Date Field

> Implementations of a SortField.getFactory().compare(FieldDoc docA, > FieldDoc docB) method could also handle any necessary decoding of > field values. Sorry that should have been SortField.getFactory().compare(Comparable fieldFromDocA, Comparable fieldFromDocB) -

RE: [Performance] Streaming main memory indexing of single strings

I think you are not approaching this the correct way. Pseudo code: Subclass IndexReader. Get tokens from String 'document' using Lucene analyzers. Build simple hash-map based data structures using tokens for terms, and term positions. reimplement termDocs() and termPositions() to use the struc

Re: [Performance] Streaming main memory indexing of single strings

Otis, this might be a misunderstanding. - I'm not calling optimize(). That piece is commented out you if look again at the code. - The *streaming* use case requires that for each query I add one (and only one) document (aka string) to an empty index: repeat N times (where N is millions or billio

DO NOT REPLY [Bug 34453] New: - Query parts ending with a colon are handled badly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34447] New: - Unmatched right parentheses truncates query

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu