Re: Threads in Solr
: Yes I do computing the same DocSet. Should it be the problem? Is any way to solve it? : In general in each thread I ran the same query and add different Filter Query. it's not neccessarily a problem, it's just that you may not get much benefit from prallelization if all of the worker threads are doing the same work simulteneously. but like i said: without knowing exactly what your threading code looks like, it's hard to guess what might be wrong (and even if i was looking right at your multithreaded code, it wouldn't neccessarily be obvious to me, my multi-threading knowledge is mediocre) and it's still not clear if you are testing on hardware that can actually take advantage of parallelization. -Hoss
range query failed if highlight is used
Hi, I'm using solr1.3 nightly build. I defined a sint field bookCount. When I query on this field, it works fine without highlight. However if I turn on highlight(hl=true&hl.fl=bookCount), it failed due to the error below. Does anyone know if this is a bug? If I change the type to integer, the highlight work, but I need to do range query on this field, so it has to be defined as sint. Thanks Xuesong 2008-02-25 16:54:53,524 ERROR [STDERR] Feb 25, 2008 4:54:53 PM org.apache.solr.core.SolrCore execute INFO: [xluo] /select/ rows=10&start=0&hl.fl=bookCount&indent=on&q=bookCount:5&hl=true&version= 2.2 0 0 2008-02-25 16:54:53,524 ERROR [STDERR] Feb 25, 2008 4:54:53 PM org.apache.solr.common.SolrException log SEVERE: java.lang.NumberFormatException: For input string: " " at java.lang.NumberFormatException.forInputString(NumberFormatException.jav a:48) at java.lang.Long.parseLong(Long.java:403) at java.lang.Long.parseLong(Long.java:461) at org.apache.solr.util.NumberUtils.long2sortableStr(NumberUtils.java:52) at org.apache.solr.schema.SortableLongField.toInternal(SortableLongField.ja va:49) at org.apache.solr.schema.FieldType$DefaultAnalyzer$1.next(FieldType.java:3 15) at org.apache.solr.highlight.TokenOrderingFilter.next(SolrHighlighter.java: 439) at org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(High lighter.java:226)
Why does highlight use the index analyzer (instead of query)?
Hi, I am using Solr 1.2.0 with a custom compound word analyzer, which inserts the decompositions into the token stream. Because I assume that when the user queries for a compound word, he is interested only in whole-word matches, I have it enabled only in my index analyzer chain. However, due to a bug in the analyzer (entirely my fault), I came to realize that when highlighting is enabled, the highlighter uses the index analyzer chain to find the matches, instead of the query analyzer chain. I find this curious, and I was wondering whether this is intentional, and if so, what is the rationale for this? Best regards - Christian
Re: can I form a SolrQuery and query a SolrServer in a request handler?
One method to generate any arbitrary query is to create your own QParser. In this case, because it's just two dismax queries, there is an easier way that I snuck in during QParser work: embedded queries. The "standard" solr query syntax (which is a slightly modified lucene query syntax) supports an embedded query via the _query_ magic field name. _query_:"+foo +bar" is equivalent to +foo +bar. So a way to embed a dismax query in a standard lucene query is: _query_:"kittens" Another way to write that is _query_:"" And yet another way (moving the query to a separate q1 parameter) is _query_:"" & q1=kittens We can specify or override other dismax params in the local params: _query_:"" & q1=kittens Here is an example of two different dismax queries with different weights on the example schema: http://localhost:8983/solr/select?q=_query_:";"^0.5 _query_:""^0.8&q1=solr&q2=ipod -Yonik On Mon, Feb 25, 2008 at 2:25 PM, Brian Whitman <[EMAIL PROTECTED]> wrote: > > > > Perhaps back up and see if we can do this a simpler way than a request > > handler... > > What is the query structure you are trying to generate? > > > > I have two dismax queries defined in a solrconfig. Something like > > > ... > > raw^4 name^1 > > > > > ... > > tags^3 type^2 > > > > They work fine on their own, and we often use &bf=sortable^... to > change the ordering. But we want to merge them. Result IDs that show > up in both need to go higher and with a url param we need to weight > between the two. So I am making a /combined requesthandler that takes > the query, the weights between the two and the value of the > bf=sortable boost. > > My handler: /combined?q=kittens&q1=0.5&q2=0.8&bfboost=2.0 > > Would query ?qt=q1&q=kittens&bf=2&fl=id, then ? > qt=q2&q=kittens&bf=2&fl=id. The request handler would return the > results of a term query with the (q1 returned IDs)^0.5 (q2 returned > IDs)^0.8. > > > > > > >
Re: can I form a SolrQuery and query a SolrServer in a request handler?
Would query ?qt=q1&q=kittens&bf=2&fl=id, then ? qt=q2&q=kittens&bf=2&fl=id. Sorry, I meant: ?qt=q1&q=kittens&bf=sortable^2&fl=id, then ? qt=q2&q=kittens&bf=sortable^2&fl=id
Re: can I form a SolrQuery and query a SolrServer in a request handler?
Perhaps back up and see if we can do this a simpler way than a request handler... What is the query structure you are trying to generate? I have two dismax queries defined in a solrconfig. Something like ... raw^4 name^1 ... tags^3 type^2 They work fine on their own, and we often use &bf=sortable^... to change the ordering. But we want to merge them. Result IDs that show up in both need to go higher and with a url param we need to weight between the two. So I am making a /combined requesthandler that takes the query, the weights between the two and the value of the bf=sortable boost. My handler: /combined?q=kittens&q1=0.5&q2=0.8&bfboost=2.0 Would query ?qt=q1&q=kittens&bf=2&fl=id, then ? qt=q2&q=kittens&bf=2&fl=id. The request handler would return the results of a term query with the (q1 returned IDs)^0.5 (q2 returned IDs)^0.8.
Re: can I form a SolrQuery and query a SolrServer in a request handler?
On Mon, Feb 25, 2008 at 2:07 PM, Brian Whitman <[EMAIL PROTECTED]> wrote:
> I'm in a request handler: public void
> handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) {
>
> And in here i want to form a SolrQuery based on the req, query the
> searcher and return results.
>
> But how do I get a SolrServer out of the req? I can get a
> SolrIndexSearcher but that doesn't seem to let me pass in a SolrQuery.
>
> I need a SolrQuery because I am forming a dismax query with a function
> query, etc...
Perhaps back up and see if we can do this a simpler way than a request
handler...
What is the query structure you are trying to generate?
-Yonik
can I form a SolrQuery and query a SolrServer in a request handler?
I'm in a request handler: public void
handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) {
And in here i want to form a SolrQuery based on the req, query the
searcher and return results.
But how do I get a SolrServer out of the req? I can get a
SolrIndexSearcher but that doesn't seem to let me pass in a SolrQuery.
I need a SolrQuery because I am forming a dismax query with a function
query, etc...
protwords | synonyms | elevator conf files
Hello! All these configuration files seem like they could be stored in a database just as well as they are stored in the file structure. Specifically the new elevator handler (which looks to be exactly what I needed, thanks!!) would be more useful if it could get its configuration from a database. Has anyone thought about linking these conf files into a database? Currently I'm dumping the DB out to the file structure and restarting solr to read in the changes - is there a better way? One that doesn't clear all the caches, perhaps? Thanks! Matthew Runo Software Developer Zappos.com 702.943.7833
Re: Search terms in the result
Chris, Thank you for answering my question, but maybe I wasn't clear in explaining it. In fact, what I meant was that using the Query compilation in Lucene you can obtain an array of strings containing the terms used from the system to search the indices. The reason I'm asking this because, depending on the Analyzer implementation (eg. StopWordsAnalyzer) or from the form of the query (eg. "the terms" to search) some words in it could be ignored. I would like to provide users with the list of the terms we run the search on and I was wondering if is it there a way to get these terms back from the system. Thank you again. Antonello On Mon, Feb 25, 2008 at 8:23 AM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > : clarification about the XML format returned by a search query: in > > : fact, I cannot find any official document describing the precise > : format of the document returned. > > that's because no one has every really taken much time to document it .. > in general the XML format is considered fairly "self describing" ... the > interesting variations come about depending on what request handler you > use (the XML format is extremely generic, request handlers can put almost > any data into it as long as the data can be described in terms of simple > datastructures) > > > : Particularly, I'm interested in understanding if search terms of the > > : query would be returned in the result, as happens in Lucene. > > i'm not sure what you mean by "as happens in Lucene" but there is a > core request params that cna be used to force the response writer to > include input params in the response: "echoParams" ... you can also use > "debugQuery" to get debugging oriented information in the response (that > includes info on the query executed. > > http://wiki.apache.org/solr/CoreQueryParameters > http://wiki.apache.org/solr/CommonQueryParameters > > > > > -Hoss > >
Re: Threads in Solr
Yes I do computing the same DocSet. Should it be the problem? Is any way to solve it? In general in each thread I ran the same query and add different Filter Query. - Original Message From: Chris Hostetter <[EMAIL PROTECTED]> To: Solr User Sent: Monday, February 25, 2008 2:19:02 AM Subject: Re: Threads in Solr : I was thinking may be I could run those queries not one by one but in : parallel, in separate threads. But it appears that it takes longer than : to run queries one by one. : Do you have any idea why? Do you think the idea to run those queries in : separate threads is good in general? Are SolrIndexSearcher and : SimpleFacets thread safe? SolrIndexSearcher is threadsafe ... SimpleFacets should be thread safe, but i won't swear to it off the top of my head. without seeing exactly how you setup your threads, it's hard to guess ... in general multiple threads are only useful if you are io bound, or have hardware that can take advantage of parallelization (ie: multiple cores). but it's also possible that things take just as long because all of your threads wind up computing the same DocSets at the same time -- or block on generating the same FieldCache arrays at the same time. -Hoss
Re: Field specific synonyms
I believe the answer is you will need to have a different field type for each. Just copy the text field type and name it text-abcd, etc. with each one configured to use the synonym file you want. -Grant On Feb 25, 2008, at 6:22 AM, Nikhil Chhaochharia wrote: Hi, I am using the 'text' fieldType from the sample schema.xml of Solr. I have multiple fields which are of 'text' type but I want to use separate synonym files for each of the fields. For example, SynonymFilter should use synonym_abcd.txt for the field named 'abcd' and synonym_xyz.txt for the field named 'xyz'. Any suggestions on how to achieve this? I am using the latest nightly build of Solr. Thanks, Nikhil
Re: Field specific synonyms
On Mon, Feb 25, 2008 at 6:22 AM, Nikhil Chhaochharia <[EMAIL PROTECTED]> wrote: > I am using the 'text' fieldType from the sample schema.xml of Solr. > > I have multiple fields which are of 'text' type but I want to use separate > synonym files for each of the fields. For example, SynonymFilter should use > synonym_abcd.txt for the field named 'abcd' and synonym_xyz.txt for the field > named 'xyz'. > > Any suggestions on how to achieve this? I am using the latest nightly build > of Solr. Make a different text field (e.g. text1, text2, text3) for each one. Use the original text field as a template (just change the name and the synonym file). -Yonik
Re: CorruptIndexException: unknown format version: -3
Maybe double check your CLASSPATHs? Because, based on the line numbers in the exception, it really looks like it's Lucene 2.1 that's trying to open a Lucene 2.2+ index. The term infos file (.tii, .tis) changed from -2 -> -3 format in 2.3. Mike On Feb 25, 2008, at 7:19 AM, Paul Danese wrote: 2Unfortunately, the answer is "no". I didn't use an upgraded version of lucene or solr. this is the bizzarre issue. I'm actually using solr via the acts_as_solr plugin used in ruby. At the time, I was adding a few 100-thousand docs to the index...there appears to have been a memory leak as my app failed with a java outofmemoryerror. i stopped everything, ran an "optimize index" and ever since then the index is unreadable via solr...even though luke can see the index and search it quite easily. Walter Ferrara <[EMAIL PROTECTED]> wrote: did you create/modify the index with a newer version of lucene than the one you use in solr? In this case I doubt you can downgrade your index, but maybe you can upgrade lucene in your solr (search in this forum, there should be a thread about this), (or try with the latest nightly builds) Paul Danese wrote: 2Hi all, Is there any way to recover from such an error as listed in the subject heading? Luke can view the index just fine (at least at a cursory level Luke is able to open the index, give me back the # of docs, etc.), but solr throws this exception whenever I try and start it up. any ideas on how to proceed? can I use luke or something else to "uncorrupt", modify or save my index into a non-corrupt format? TIA!! org.apache.solr.core.SolrException log SEVERE: java.lang.RuntimeException: org.apache.lucene.index.CorruptIndexException: Unknown format version:-3 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java: 433) at org.apache.solr.core.SolrCore.(SolrCore.java:216) at org.apache.solr.core.SolrCore.getSolrCore(SolrCore.java: 177) at org.apache.solr.servlet.SolrDispatchFilter.init (SolrDispatchFilter.java:69) at org.mortbay.jetty.servlet.FilterHolder.doStart (FilterHolder.java:99) at org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:40) at org.mortbay.jetty.servlet.ServletHandler.initialize (ServletHandler.java:594) at org.mortbay.jetty.servlet.Context.startContext (Context.java:139) at org.mortbay.jetty.webapp.WebAppContext.startContext (WebAppContext.java:1218) at org.mortbay.jetty.handler.ContextHandler.doStart (ContextHandler.java:500) at org.mortbay.jetty.webapp.WebAppContext.doStart (WebAppContext.java:448) at org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart (HandlerCollection.java:147) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart (ContextHandlerCollection.java:161) at org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart (HandlerCollection.java:147) at org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart (HandlerWrapper.java:117) at org.mortbay.jetty.Server.doStart(Server.java:210) at org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:40) at org.mortbay.xml.XmlConfiguration.main (XmlConfiguration.java:929) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.mortbay.start.Main.invokeMain(Main.java:183) at org.mortbay.start.Main.start(Main.java:497) at org.mortbay.start.Main.main(Main.java:115) Caused by: org.apache.lucene.index.CorruptIndexException: Unknown format version:-3 at org.apache.lucene.index.SegmentTermEnum. (SegmentTermEnum.java:64) at org.apache.lucene.index.TermInfosReader. (TermInfosReader.java:49) at org.apache.lucene.index.SegmentReader.initialize (SegmentReader.java:184) at org.apache.lucene.index.SegmentReader.get (SegmentReader.java:157) at org.apache.lucene.index.SegmentReader.get (SegmentReader.java:139) at org.apache.lucene.index.IndexReader$1.doBody (IndexReader.java:194) at org.apache.lucene.index.SegmentInfos $FindSegmentsFile.run(SegmentInfos.java:610) at org.apache.lucene.index.IndexReader.open (IndexReader.java:184) at org.apache.lucene.index.IndexReader.open (IndexReader.java:148) at org.apache.solr.search.SolrIndexSearcher. (SolrIndexSearcher.java:87) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java: 424)
Re: CorruptIndexException: unknown format version: -3
2Unfortunately, the answer is "no". I didn't use an upgraded version of lucene or solr. this is the bizzarre issue. I'm actually using solr via the acts_as_solr plugin used in ruby. At the time, I was adding a few 100-thousand docs to the index...there appears to have been a memory leak as my app failed with a java outofmemoryerror. i stopped everything, ran an "optimize index" and ever since then the index is unreadable via solr...even though luke can see the index and search it quite easily. Walter Ferrara <[EMAIL PROTECTED]> wrote: did you create/modify the index with a newer version of lucene than the one you use in solr? In this case I doubt you can downgrade your index, but maybe you can upgrade lucene in your solr (search in this forum, there should be a thread about this), (or try with the latest nightly builds) Paul Danese wrote: > 2Hi all, > > Is there any way to recover from such an error as listed in the subject > heading? > > Luke can view the index just fine (at least at a cursory level Luke is able > to open the index, give me back the # of docs, etc.), but solr throws this > exception whenever I try and start it up. > > any ideas on how to proceed? > can I use luke or something else to "uncorrupt", modify or save my index into > a non-corrupt format? > > TIA!! > > > org.apache.solr.core.SolrException log > SEVERE: java.lang.RuntimeException: > org.apache.lucene.index.CorruptIndexException: Unknown format version:-3 > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:433) > at org.apache.solr.core.SolrCore.(SolrCore.java:216) > at org.apache.solr.core.SolrCore.getSolrCore(SolrCore.java:177) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:69) > at > org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.mortbay.start.Main.invokeMain(Main.java:183) > at org.mortbay.start.Main.start(Main.java:497) > at org.mortbay.start.Main.main(Main.java:115) > Caused by: org.apache.lucene.index.CorruptIndexException: Unknown format > version:-3 > at org.apache.lucene.index.SegmentTermEnum.(SegmentTermEnum.java:64) > at org.apache.lucene.index.TermInfosReader.(TermInfosReader.java:49) > at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:184) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:157) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:139) > at org.apache.lucene.index.IndexReader$1.doBody(IndexReader.java:194) > at > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:610) > at org.apache.lucene.index.IndexReader.open(IndexReader.java:184) > at org.apache.lucene.index.IndexReader.open(IndexReader.java:148) > at > org.apache.solr.search.SolrIndexSearcher.(SolrIndexSearcher.java:87) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:424) > ... 27 more > > > > > > > - > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now. > - Looking
Re: CorruptIndexException: unknown format version: -3
did you create/modify the index with a newer version of lucene than the one you use in solr? In this case I doubt you can downgrade your index, but maybe you can upgrade lucene in your solr (search in this forum, there should be a thread about this), (or try with the latest nightly builds) Paul Danese wrote: 2Hi all, Is there any way to recover from such an error as listed in the subject heading? Luke can view the index just fine (at least at a cursory level Luke is able to open the index, give me back the # of docs, etc.), but solr throws this exception whenever I try and start it up. any ideas on how to proceed? can I use luke or something else to "uncorrupt", modify or save my index into a non-corrupt format? TIA!! org.apache.solr.core.SolrException log SEVERE: java.lang.RuntimeException: org.apache.lucene.index.CorruptIndexException: Unknown format version:-3 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:433) at org.apache.solr.core.SolrCore.(SolrCore.java:216) at org.apache.solr.core.SolrCore.getSolrCore(SolrCore.java:177) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:69) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594) at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) at org.mortbay.jetty.Server.doStart(Server.java:210) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.mortbay.start.Main.invokeMain(Main.java:183) at org.mortbay.start.Main.start(Main.java:497) at org.mortbay.start.Main.main(Main.java:115) Caused by: org.apache.lucene.index.CorruptIndexException: Unknown format version:-3 at org.apache.lucene.index.SegmentTermEnum.(SegmentTermEnum.java:64) at org.apache.lucene.index.TermInfosReader.(TermInfosReader.java:49) at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:184) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:157) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:139) at org.apache.lucene.index.IndexReader$1.doBody(IndexReader.java:194) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:610) at org.apache.lucene.index.IndexReader.open(IndexReader.java:184) at org.apache.lucene.index.IndexReader.open(IndexReader.java:148) at org.apache.solr.search.SolrIndexSearcher.(SolrIndexSearcher.java:87) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:424) ... 27 more - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Field specific synonyms
Hi, I am using the 'text' fieldType from the sample schema.xml of Solr. I have multiple fields which are of 'text' type but I want to use separate synonym files for each of the fields. For example, SynonymFilter should use synonym_abcd.txt for the field named 'abcd' and synonym_xyz.txt for the field named 'xyz'. Any suggestions on how to achieve this? I am using the latest nightly build of Solr. Thanks, Nikhil
CorruptIndexException: unknown format version: -3
2Hi all, Is there any way to recover from such an error as listed in the subject heading? Luke can view the index just fine (at least at a cursory level Luke is able to open the index, give me back the # of docs, etc.), but solr throws this exception whenever I try and start it up. any ideas on how to proceed? can I use luke or something else to "uncorrupt", modify or save my index into a non-corrupt format? TIA!! org.apache.solr.core.SolrException log SEVERE: java.lang.RuntimeException: org.apache.lucene.index.CorruptIndexException: Unknown format version:-3 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:433) at org.apache.solr.core.SolrCore.(SolrCore.java:216) at org.apache.solr.core.SolrCore.getSolrCore(SolrCore.java:177) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:69) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594) at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) at org.mortbay.jetty.Server.doStart(Server.java:210) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.mortbay.start.Main.invokeMain(Main.java:183) at org.mortbay.start.Main.start(Main.java:497) at org.mortbay.start.Main.main(Main.java:115) Caused by: org.apache.lucene.index.CorruptIndexException: Unknown format version:-3 at org.apache.lucene.index.SegmentTermEnum.(SegmentTermEnum.java:64) at org.apache.lucene.index.TermInfosReader.(TermInfosReader.java:49) at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:184) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:157) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:139) at org.apache.lucene.index.IndexReader$1.doBody(IndexReader.java:194) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:610) at org.apache.lucene.index.IndexReader.open(IndexReader.java:184) at org.apache.lucene.index.IndexReader.open(IndexReader.java:148) at org.apache.solr.search.SolrIndexSearcher.(SolrIndexSearcher.java:87) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:424) ... 27 more - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: Newbie question about search
: Once I post it I see following entry in my catalina.out. However when I go : to solr search page and try to search any token in content sectionI do not : get any thing returned. basically : : the logs you posted don't inlcude anything about the query you executed, so it's hard to guess what might be going wrong. have you tried seraching for *:* to see if the documents are in there are all? have you looked at the LukeRequestHandler to see what terms have been indexed in the contents field? -Hoss
Re: custom handler results don't seem to match manually entered query string
: But I always thought such code:
:
: Term term = new Term("text", str);
: TermQuery tq = new TermQuery(term);
: query.add(tq, Occur.SHOULD);
:
: would get query terms through analyzers - since they are specified under
the underlying lucene query classes (like TermQuery) don't know anything
baout analyzers -- definitely nothing about Solr specific field types.
if you think about it: it would be impossible for them to: if you've got a
quoted string like "foo bar" you need to analyze it in order to know
wether it should be a single TermQuery (because of KeywordTokenizer), a
PhraseQuery with two terms (because of whitespace tokenizer), a
PhraseQuery with a dozen terms (because of an ngram tokenizer) or a
MultiTermPrahseQuery (because of a synonym filter)
it's the SolrQueryParser that knows about the FieldTypes in the schema.xml
-Hoss
