i find it will be OutOfMemory when i get more that 10k records.
so now i index 10k records( 5k / record)
if i use for to index more data. it always show OutOfMemory.
i use top to moniter and find index finish, free memory is 125m,,and
sometime it will be 218m
it show me solr index finish and
I don't use Filters very much so this might be a dumb question, but I
could overcome the main drawback by hooking into the filter and
updating it's bits without affecting the caching, right?
I kind of think I have scaling issues no matter what. If you do the
post processing way, then you m
12 apr 2007 kl. 17.06 skrev Yonik Seeley:
Sorting works on indexed tokens, and hence doesn't really work on
analyzed fields that produce more than one token per document. I
suspect your title field falls into that category. You could also
index the title field into another field that is index
On 4/13/07, James liu <[EMAIL PROTECTED]> wrote:
i find it will be OutOfMemory when i get more that 10k records.
so now i index 10k records( 5k / record)
In one request? There's really no reason to put more than hundreds of
documents in a single add request.
If you are indexing using multipl
On 4/13/07, karl wettin <[EMAIL PROTECTED]> wrote:
It just hit me (and I did not consider it any further) that perhaps
one could store String.valueOf(theTitle.hashcode()) in an alternative
field and sort by that instead? It will not be 100% accurate, but in
most cases it will.
That would only m
13 apr 2007 kl. 15.48 skrev Yonik Seeley:
On 4/13/07, karl wettin <[EMAIL PROTECTED]> wrote:
It just hit me (and I did not consider it any further) that perhaps
one could store String.valueOf(theTitle.hashcode()) in an alternative
field and sort by that instead? It will not be 100% accurate, b
Hi there,
I'm building an index to which I'm sending a few hundred thousand
entries. I pull them off the database in batches of 25k and send them to
solr, 100 documents at a time. I was doing a commit after each of those
but after what Yonik says I will remove it and commit only after each
ba
Yonik Seeley wrote:
Oh wait... Andrew, were you always testing via "ping"?
Check out what the ping query is configured as in solrconfig.xml:
qt=dismax&q=solr&start=3&fq=id:[* TO *]&fq=cat:[*
TO *]
Perhaps we should change it to something simple by default??? "q=solr"?
That solv
I'm trying to choose between embedding Lucene versus embedding Solr in one
webapp.
In Solr terms, functional requirements would more or less lead to multiple
schema & conf (need CRUD/generation on those) and deployment constraints
imply one webapp instance. The choice I'm trying to make is thus:
First off, I am aware that the bulk of this question has to do with
Jetty, but please have kindness...
My end goal is to have a handful of Solr instances running under Jetty
all accessible at
/app1
/app2
...etc...
I have taken the .war file in the Solr dist/ directory, unpacked it
and added in
: I don't use Filters very much so this might be a dumb question, but I
: could overcome the main drawback by hooking into the filter and
: updating it's bits without affecting the caching, right?
Not really ... Solr doesn't use Filter's the same way as
CachingWrapperFilter does ... it builds Doc
: That might be true, as I said, I didn't really think about it too
: long. But some alternative hashCode could probably be implemented,
: one that use all available bits in a string, rather than the 32 bit
: limitation of an integer.
if you're going to use all the bits in the string, and not con
On 4/13/07, Henrib <[EMAIL PROTECTED]> wrote:
I'm trying to choose between embedding Lucene versus embedding Solr in one
webapp.
In Solr terms, functional requirements would more or less lead to multiple
schema & conf (need CRUD/generation on those) and deployment constraints
imply one webapp i
Hi -
Of the various approaches that you could take, the one I'd work on first is:
deployment constraints imply one webapp instance.
In most environments, it's going to cost a lot less to change this, than to
try to roll your own, or extensively modify solr.
I know I'm sidestepping your state
13 apr 2007 kl. 20.11 skrev Chris Hostetter:
: That might be true, as I said, I didn't really think about it too
: long. But some alternative hashCode could probably be implemented,
: one that use all available bits in a string, rather than the 32 bit
: limitation of an integer.
if you're goi
Thank you both for your quick answers.
The one webapp constraint comes from the main 'embedding' application so I
don't have much leeway there. The direct approach was to map the
main/hosting application document collection & types to one schema/conf.
Since the host collections & types can be dyn
I wrote the following after hurriedly reading Grant Ingersoll's
question, and I completely missed the "to remove results that have
already been viewed" bit. Which leads me to think what I wrote may
have no bearing on this issue... but perhaps it may have bearing on
someone else's issue?
- J
: but does not want to deal with the application itself, leaving the 'business
: users' side administer it. Even if there is a dedicated Tomcat for the main
: app, IT will not let the 'business users' install other applications (scope
: of responsibility, code versus data, validation procedures, e
I think you're on to something, here was the output:
# Licensed to the Apache Software Foundation (ASF) under one or more^M$
# contributor license agreements. See the NOTICE file distributed with^M$
# this work for additional information regarding copyright ownership.^M$
# The ASF licenses this
19 matches
Mail list logo
