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
: 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 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
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
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
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
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
: 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
: 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
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'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:
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
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
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
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
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
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
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
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
19 matches
Mail list logo
