yes i was thinking abt the same. i was searching for a radius of 25 miles. we get about 2500 results back for the search. it seems like its storing all those geo results in cache and it keeps on adding to it each time a geo request is made...
thanks for looking into it! Sandeep -----Original Message----- From: patrick o'leary [mailto:[EMAIL PROTECTED] Sent: 28 September 2007 17:02 To: solr-user@lucene.apache.org Subject: Re: locallucene former custom-sort thread That's the latest. I was experimenting with caching, which might be the problem. I'll have a look, could you give me an idea of how large the radius was and how many results were coming back. Thanks P Sandeep Shetty wrote: > Hi, i'm using local lucene, downloaded the latest zip file > solr-example_s1.3_ls0.2.tgz > > is there a newer version available? > > Thanks! > Sandeep > > -----Original Message----- > From: patrick o'leary [mailto:[EMAIL PROTECTED] > Sent: 28 September 2007 16:08 > To: solr-user@lucene.apache.org > Subject: locallucene former custom-sort thread > > > Changing thread name; > > Are you using local lucene or local solr, and which version? > > > P > > [EMAIL PROTECTED] wrote: > >> i have been testing locallucene with our data for the last couple of days. >> one issue i faced with it is during when using geo sorting is that it >> > seems > >> to eat up all the memory, however big and become progressively slower, >> finally after several requests (10 or so in my case) it throws up a >> java.lang.OutOfMemoryError: Java heap space error. >> >> is there a way to get around this? >> >> -----Original Message----- >> From: Jon Pierce [mailto:[EMAIL PROTECTED] >> Sent: 28 September 2007 15:48 >> To: solr-user@lucene.apache.org >> Subject: Re: custom sorting >> >> >> Is the machinery in place to do this now (hook up a function query to >> be used in sorting)? >> >> I'm trying to figure out what's the best way to do a distance sort: >> custom comparator or function query. >> >> Using a custom comparator seems straightforward and reusable across >> both the standard and dismax handlers. But it also seems most likely >> to impact performance (or at least require the most work/knowledge to >> get right by minimizing calculations, caching, watching out for memory >> leaks, etc.). (Speaking of which, could anyone with more Lucene/Solr >> experience than I comment on the performance characteristics of the >> locallucene implementation mentioned on the list recently? I've taken >> a first look and it seems reasonable to me.) >> >> Using a function query, as Yonik suggests above, is another approach. >> But to get a true sort, you have to boost the original query to zero? >> How does this impact the results returned by the original query? Will >> the requirements (and boosts) of the original (now nested) query >> remain intact, only sorted by the function? Also, is there any way to >> do this with the dismax handler? >> >> Thanks, >> - Jon >> >> On 9/27/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: >> >> >>>> On 9/27/07, Erik Hatcher <[EMAIL PROTECTED]> wrote: >>>> >>> >>> >>>>>> Using something like this, how would the custom SortComparatorSource >>>>>> get a parameter from the request to use in sorting calculations? >>>>>> >>>> >>>> >>>> perhaps hook in via function query: >>>> dist(10.4,20.2,geoloc) >>>> >>>> And either manipulate the score with that and sort by score, >>>> >>>> q=+(foo bar)0 dist(10.4,20.2,geoloc) >>>> sort=score asc >>>> >>>> or extend solr's sorting mechanisms to allow specifying a function to >>>> > sort > >>> >>> >> by. >> >> >>>> sort="dist(10.4,20.2,geoloc) asc" >>>> >>>> -Yonik >>>> >>>> >>> >>> >> This email is confidential and may also be privileged. If you are not the >> > intended recipient please notify us immediately by telephoning +44 (0)20 > 7452 5300 or email [EMAIL PROTECTED] You should not copy it or use > it for any purpose nor disclose its contents to any other person. Touch > Local cannot accept liability for statements made which are clearly the > sender's own and are not made on behalf of the firm. > >> Touch Local Limited >> Registered Number: 2885607 >> VAT Number: GB896112114 >> Cardinal Tower, 12 Farringdon Road, London EC1M 3NN >> +44 (0)20 7452 5300 >> >> >> > > -- Patrick O'Leary AOL Local Search Technologies Phone: + 1 703 265 8763 You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. - Albert Einstein View Patrick O Leary's LinkedIn profileView Patrick O Leary's profile <http://www.linkedin.com/in/pjaol>
