Hello,
I saw same error. The cause of this problem is there are two
lucene-analyzers*.jar
files in trunk.
$ find . -name "lucene-analyzers-*.jar"
./client/ruby/solr-ruby/solr/lib/lucene-analyzers-2.2-dev.jar
./lib/lucene-analyzers-2.2.0.jar
To eliminate error on eclipse, remove lucene-analyze
Are there any known Solr sites that are in Chinese or Japenese?
I need to include links to such sites for a comparison I'm doing on
enterprise search engines.
I realize that if I stay UTF-8 it should work and I can use the CJK
analyzer.
Paul Sundling
Has anyone looked into using carrot2 clustering with solr?
I know this is integrated with nutch:
http://lucene.apache.org/nutch/apidocs/org/apache/nutch/clustering/carrot2/Clusterer.html
It looks like carrot has support to read results from a solr index:
http://demo.carrot2.org/head/api/org/carr
On Jul 26, 2007, at 11:49 AM, Yonik Seeley wrote:
Could you try it with jetty to see if it's the servlet container?
It should be simple to just copy the index directory into solr's
example/solr/data directory.
Yonik, sorry for my delay, but I did just try this in jetty -- it
works (it doe
Nice, valid xml. But If I have an error (for example, ) I
get an HTML page back.
In 1.2, if you map /update to the XmlUpdateHandler in solrconfig.xml,
errors are returned with an HTTP status error (ie, something != 200) +
message. Your servlet runner (Jetty, Tomcat, etc) will format this as
Hi -
With solr 1.2, when using XmlUpdateRequestHandler , if I post a valid
command like "" I get a response like
00
Nice, valid xml. But If I have an error (for example, ) I
get an HTML page back.
This tends to confuse the client software. Is there a way to get a return
like:
1blah, blah
Thank you, I'll take a look.
Pieter Berkel wrote:
>
> 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 inc
nithyavembu wrote:
Hi Otis Gospodnetic,
Thanks for the reply. I tried with this URL, its working but its not
checking the condition. Its showing all the records if i use this URL. Is
there any solution
I'm not sure about the order of operations, but try:
+FID:8 +RES_TYPE:0 RES_TYPE:1
Hi Otis Gospodnetic,
Thanks for the reply. I tried with this URL, its working but its not
checking the condition. Its showing all the records if i use this URL. Is
there any solution
Thanks in advance.
Regards,
V.Nithya.
Otis Gospodnetic wrote:
>
> Have you tried this:
>
> http://l
Try leaving of the "q" param and using "q.alt=*:*"
On 7/26/07, Alexandru Badiu <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Since it's my first email to this list I want to say thank you for a
> wonderful piece of software.
>
> Now, onto more serious business. :) I switched from the standard
> request
On 7/26/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
>
> On Jul 26, 2007, at 11:25 AM, Yonik Seeley wrote:
>
> > OK, then perhaps it's a jetty bug with charset handling.
> >
>
> I'm using resin btw
Could you try it with jetty to see if it's the servlet container?
It should be simple to just copy t
On Jul 26, 2007, at 11:25 AM, Yonik Seeley wrote:
OK, then perhaps it's a jetty bug with charset handling.
I'm using resin btw
Could you run the same query, but use the python output?
wt=python
Seems to be OK:
{'responseHeader':{'status':0,'QTime':0,'params':{'start':'7','fl':'c
onten
On 7/26/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
>
> On Jul 26, 2007, at 11:10 AM, Yonik Seeley wrote:
>
> >
> > If the '<' truely got destroyed, it's a server (Solr or Jetty) bug.
> >
> > One possibility is that the '<' does exist, but due to a charset
> > mismatch, it's being slurped into a m
I've filed this as https://issues.apache.org/jira/browse/SOLR-320
Sorry for the mixups!
Stu
-Original Message-
From: Ryan McKinley <[EMAIL PROTECTED]>
Sent: Thu, July 26, 2007 1:27 am
To: solr-user@lucene.apache.org
Subject: Re: Problems with embedded Solr
no attachments came throug
On Jul 26, 2007, at 11:10 AM, Yonik Seeley wrote:
If the '<' truely got destroyed, it's a server (Solr or Jetty) bug.
One possibility is that the '<' does exist, but due to a charset
mismatch, it's being slurped into a multi-byte char.
Just dumped it with curl and did a hexdump:
5a0
On 7/26/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
> I ended up with this doc in solr:
>
>
>
> 0 name="QTime">17 name="fl">content"Pez"~1 name="rows">1 numFound="5381" start="7">Akatsuki - PE'Z
> ҳ | ̳ | պ | ŷ | >>> Akatsuki - PE'Z ר | и |
> Ů | ֶ | պ | ¸ | tӺ
> &
Looks to me as if your document is not valid UTF-8 and is missing one
byte at the end.
Then the '<' of '' is included into the previous character.
Did you create the text snippet yourself? Maybe check if the string
functions you are using are multi-byte aware.
Greetings, Marc
On 26-jul-2
I ended up with this doc in solr:
0name="QTime">17name="fl">content"Pez"~1name="rows">1numFound="5381" start="7">Akatsuki - PE'Z
ҳ | ̳ | պ | ŷ | >>> Akatsuki - PE'Z ר | и |
Ů | ֶ | պ | ¸ | tӺ
| Ϸ | Ӱ | ϼ | ŷ>
| ϸ | ѵ ŷ> >
The previous message that came through with no body holds the attachment.
I believe my issue is due to threads... after using JDB on the app I attached,
I noticed one of the threads created by the SolrCore doesn't die after the core
is closed. I need the thread to die on its own, because calli
Hello,
Since it's my first email to this list I want to say thank you for a
wonderful piece of software.
Now, onto more serious business. :) I switched from the standard
request handler to the dismax one to use boosting. Using the std one
I was using a q=*:* to retrieve all records from s
hello solrs!
when using the collapse feature of solr 236 and faceting, the faceting happens
after the collapse. Is there a way to do faceting before collapsing?
-
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers -
21 matches
Mail list logo
