There is a known issue with the DistanceComparatorSource in the "Lucene in Action" source code:

        <http://www.lucenebook.com/blog/errata/2006/03/01/memory_leak.html>

Maybe this advice will help fix the issue you're having?

        Erik


On Jul 17, 2006, at 9:54 AM, Aleksey Serba wrote:

Hi!

Peter, I have exactly the same situation described below.
- I have DistanceComparatorSource to sort results by distance from
specified spatial coordinates point. Point is different for each
query.
- I do not close Searcher after each query.
- I get "java.lang.OutOfMemoryError: Java heap space" after several
request. Using www.yourkit.com's profiler and research lucene source
code i've found sort comparators caching and there's no any options.

Peter, did you find the solution do not cache these sorting values?


Yonik, thank you for your suggestion, we use solr codebase already :)
To tell the truth, first time i thought this is solr caching problem (
i've modify SolrIndexSearcher to get lucene Searcher and search
directly without any solr caching )

I can't figure out how to use FunctionQuery - is there any wiki pages
/ examples or something?

Thanks

Alex

On 5/18/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
Suppose I have a custom sorting 'DocScoreComparator' for computing distances
on each search hit from a specified coordinate (similar to the
DistanceComparatorSource example in LIA). Assume that the 'specified
coordinate' is different for each query. This means a new custom comparator must be created for each query, which is ok. However, Lucene caches the comparator even though it will never be reused. This could result in heavy
memory usage if many queries are performed before the IndexReader is
updated.

Is there any way to avoid having lucene cache the custom sorting objects?



On 5/12/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:
Yes, it does compute these distances for all the terms for the field
specified, but only once (per IndexReader).  This is where the
techniques Solr employs comes in real handy... warming up caches by
running searches and sorts before putting a index into service.


On 5/12/06, Urvashi Gadi <[EMAIL PROTECTED]> wrote:
I am looking at DistanceComparatorSource class (for csutom sorting) and looks like it calculates the distance for each record in the index and not just the records returned from search, making the system very slow.

Is my observation correct? Are there ways to optimize this process?

Thanks,
Urvashi

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to