Hi,
I'm one of the developers of the initial version of OpenPipe.
We are currently using OpenPipe with Solr to index the Norwegian and
English wikipedia.
Anything in particular you want to know?
- Espen
> From: "Rogerio Pereira" <[EMAIL PROTECTED]>
> Date: 2. april 2008 23.00.32 GMT+02:00
> To
On Thu, 3 Apr 2008 18:14:56 -0300
"Jonathan Ariel" <[EMAIL PROTECTED]> wrote:
> I'm experiencing a really poor performance when using date ranges in solr
> query. Is it a know issue? is there any special consideration when using
> date ranges? It seems weird because I always thought date dates are
Is this depends on the number of documents that matches the query or the
number of documents in the index?
If in a 3 million documents index my query matches 4, having date with a
precision of seconds could slow down the query?
On Thu, Apr 3, 2008 at 7:45 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
On 3-Apr-08, at 2:14 PM, Jonathan Ariel wrote:
Hi,
I'm experiencing a really poor performance when using date ranges in
solr
query. Is it a know issue? is there any special consideration when
using
date ranges? It seems weird because I always thought date dates are
translated to strings, so
Hi,
I'm experiencing a really poor performance when using date ranges in solr
query. Is it a know issue? is there any special consideration when using
date ranges? It seems weird because I always thought date dates are
translated to strings, so internally lucene resolves everything the same
way. So
: I would like know if someone has used this framework with solr.
Didn't you just ask this question yesterday?
1) you have to be a little more patient in waiting for answers, not
everyone replies to every email immediately.
2) typically with questions like this no response (after a few days) m
I would like know if someone has used this framework with solr.
--
Yours truly (Atenciosamente),
Rogério (_rogerio_)
http://faces.eti.br
"Faça a diferença! Ajude o seu país a crescer, não retenha conhecimento,
distribua e aprenda mais." (http://faces.eti.br/?p=45)
Hello. I was wondering what happens when an add command is done without a
commit command. Is there any way to roll back?
--
View this message in context:
http://www.nabble.com/solr-commit-command-questions-tp16467824p16467824.html
Sent from the Solr - User mailing list archive at Nabble.com.
It is a POST so it's not a jetty limit.
The mysterious "4096" numbers in the string that begins
_header=[6518349,32231686,m=4,g=4096,p=4096,c=4096] ... and
"java.io.IOException: FULL" in the server traceback made me think that
the size of a static buffer is being exceeded. Since the exception
Was looking on our server and at one point there were over 13k open file descriptors for the same
spell index: /home/dsteiger/local/solr/cores/qaa/data/spell/_1ji.cfs. At some point dropped back
down to 3000 (when I checked again) with no intervention from us.
On my local machine after every
1000 filters, wow!
Perhaps you hit a jetty limit on the size of a GET request or
something? Perhaps try POST?
-Yonik
On Thu, Apr 3, 2008 at 11:03 AM, Phillip Farber <[EMAIL PROTECTED]> wrote:
> I use a filter query (fq) parameter in my requests to limit the select
> response to a subset of all
I use a filter query (fq) parameter in my requests to limit the select
response to a subset of all document ids. I'm getting a Solr exception
when the number of values in the fq approaches 1000. I get the
following response from Solr:
_header=[6518349,32231686,m=4,g=4096,p=4096,c=4096]={/so
Do the cores: newswire2, TestIndex, and core5 work on their own?
Can you load each of them into a clean multicore environment?
(Grasping here but...) perhaps there is something wrong with the
config for thoes cores and they don't initalize properly and there is
not a nice error.
Do the log
Hi Folks,
I created 5 initial cores all individual and successively named core(0-4)
This worked fine! Then I added 3 more cores: newswire2, TestIndex, and
core5.
I added newswire2 and TestIndex first then added core5, thinking it may be a
naming
issue, but these never get picked up by the server.
14 matches
Mail list logo
