no attachments came through...
Off hand, "SolrCore.close()" should not exit the program, it just closes
the searchers and cleans up after itself.
System.exit(0);
will terminate the program.
Stu Hood wrote:
I'll try that again... (don't let my e-mail failures reflect badly on Webmail.us =)
I'll try that again... (don't let my e-mail failures reflect badly on
Webmail.us =)
Hey everyone,
I'm
having some trouble getting embedded Solr working exactly as I'd like.
I've attached some code that almost works how I want it to, except that
even after calling SolrCore.close(), the program
Stu Hood wrote:
Can you resend your question without a tar file?
thanks
ryan
ahhh great help, and the analysis console rocks!
again, many thanks
alessandro ferrucci :)
On 7/25/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 7/25/07, Alessandro Ferrucci <[EMAIL PROTECTED]> wrote:
> hey guys,
>
> I'm having an issue where if I have a document where the first name is:
> R
On 7/25/07, Alessandro Ferrucci <[EMAIL PROTECTED]> wrote:
hey guys,
I'm having an issue where if I have a document where the first name is:
Ricky and the last name is: Johns
and I give such a query:
first-name:ricky* AND last-name:johns*;score desc,last-name asc,first-name
asc
I get 0 results
hey guys,
I'm having an issue where if I have a document where the first name is:
Ricky and the last name is: Johns
and I give such a query:
first-name:ricky* AND last-name:johns*;score desc,last-name asc,first-name
asc
I get 0 results back. but if I change the query to be something like
first-
Actually, sincere apologies - setting &rows=n *does* actually work, I
was just reading the results wrong.
Regards.
--Nuno
On 26 Jul 2007, at 01:03, Nuno Leitao wrote:
Hi,
Is there a way to limit the number of results returned by the
MoreLikeThis handler ?
I've tried setting &rows=n, bu
Hi,
Is there a way to limit the number of results returned by the
MoreLikeThis handler ?
I've tried setting &rows=n, but this does not have any effect. The
documentation (http://wiki.apache.org/solr/MoreLikeThis) does not
mention anything about limiting the number of returned results.
T
solr-runner.tgz
Description: application/compressed-tar
Debra,
It sounds like what you are trying to do is implemented in a new feature
known as "Field collapsing" (see
https://issues.apache.org/jira/browse/SOLR-236 for more info). Unfortunately
it isn't quite mature enough to be included in the main distribution so in
order to try it out you'll proba
Is there a way to receive only one result for each group of search results
depending on a specified group field.
Example:
Searching a list of articles with author as the group field would return
articles that match the query but will return only one article per author
even if the author has mor
On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
> On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
>> This turn out to be a bad idea ... for some reason using the
>> BoostQuery instead
>> of the BoostFunction slows the search to a crawl.
>
> Dismax throws bq in with the mai
Yonik Seeley wrote:
On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
This turn out to be a bad idea ... for some reason using the
BoostQuery instead
of the BoostFunction slows the search to a crawl.
Dismax throws bq in with the main query, so it can't really be cached
separately, so iteratin
On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
Luis Neves wrote:
> The objective is to boost the documents by "freshness" ... this is
> probably the cause of the memory abuse since all the "EntryDate" values
> are unique.
> I will try to use something like:
> EntryDate:[* TO NOW/DAY-3MONTH]^
Luis Neves wrote:
The objective is to boost the documents by "freshness" ... this is
probably the cause of the memory abuse since all the "EntryDate" values
are unique.
I will try to use something like:
EntryDate:[* TO NOW/DAY-3MONTH]^1.5
This turn out to be a bad idea ... for some reason u
Have you tried this:
http://localhost:8085/solr/select?q=FID:8+AND+RES+TYPE:0+OR+RES+TYPE:1+AND+ALL:sun&fl=ALL
The column may need to be URL-encoded.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Messa
Yonik Seeley wrote:
On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
We are having some issues with one of our Solr instances when
autowarming is
enabled. The index has about 2.2M documents and 2GB of size, so it's not
particularly big. Solr runs with "-Xmx1024M -Xms1024M".
"Big" is relative
On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
We are having some issues with one of our Solr instances when autowarming is
enabled. The index has about 2.2M documents and 2GB of size, so it's not
particularly big. Solr runs with "-Xmx1024M -Xms1024M".
"Big" is relative to what you are tryin
Luis,
This will help you spot the source of the OOM:
$ jps
$ jmap -histo:live | head -20
Do that a few times while auto-warming is happening and you'll see what's
growing.
I'm assuming you are using java 1.6.
Otis
--
Lucene Consulting -- http://lucene-consulting.com/
- Original Message
Hello all.
We are having some issues with one of our Solr instances when autowarming is
enabled. The index has about 2.2M documents and 2GB of size, so it's not
particularly big. Solr runs with "-Xmx1024M -Xms1024M".
We are constantly inserting and updating the index, about 20 new/updated
d
20 matches
Mail list logo
