Searching "inside of words"
Hi, I'm still pretty new to Solr. We're using it for searching on our site right now though. The configuration is however pretty much based on the example-files that come with Solr and there's one type of search that I can't get to work. Each item has fields called "title" and "description", both of which are of type "text". The type "text" is defined like this in our schema.xml : words="stopwords.txt"/> generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0"/> ignoreCase="true" expand="true"/> words="stopwords.txt"/> generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0"/> My problem is that if I have an item with "title"="Termobyxa", a search for "Termo" gives me a hit but if I search for "ermo" or "byxa" I get no hit. How do I make it so that this kind of search "inside a word" returns a hit? Sincerely, Daniel Löfquist
Updating documents in Solr
Hi! There are any option to update a field (or a set of fields) of a document indexed in Solr,without having to update all the fields of the entire document??? I have seen the SOLR-139 patch,but I do not know what is the proper syntax of the command (or the xml to post) to update the document.Please,I hope any suggestion!!! For example,something like this: SOLR1000 9 Regards.. -- View this message in context: http://www.nabble.com/Updating-documents-in-Solr-tp16742850p16742850.html Sent from the Solr - User mailing list archive at Nabble.com.
config for very frequent solr updates
hi all :) I didn't see any documentation on this, so I was wondering what the experience here was with updating solr with a small but constant trickle of daemon-style updates. unfortunately, it's a business requirement that backend db updates make it to search as the changes roll in (5 minutes is out of the question). with the way solr handles new searchers, warming, etc, I was wondering if anyone had experience with this kind of thing and could share thoughts/general config stuff on it. thanks. --Geoff
operator in Dismax??
Hi , I had a doubt regarding using operator in dismax handler that if i could use OR, AND, NOT operators in dismax, as they are used in standard handler. I tried using OR operator as used in standard handler but got unexpected results. Thanks. M.Hasan Muddassir Hasan - Did you know? You can CHAT without downloading messenger. Click here
Re: too many queries?
Ok. So I tried with less cache as I told you, but the server goes down after a while. I will use jconsole to monitor the servers and see what happens. Maybe it is a memory issue? With the cache changes I noticed that there are no evictions at all and the facet query time went from 500ms to 80ms in most of the cases. I tried commiting every 5 minutes instead of 2 minutes, but eventually the server stop responding. I could see that there are lots of open and active connections to solr in that moment, so I assume that maybe the warmups or the commits causes a bottleneck. Anyways, I'll try jconsole and let you know. On Wed, Apr 16, 2008 at 5:32 PM, oleg_gnatovskiy < [EMAIL PROTECTED]> wrote: > > Oh ok. That makes sense. Thanks. > > Otis Gospodnetic wrote: > > > > Oleg, you can't explicitly say "N GB for index". Wunder was just saying > > how much you can imagine how much RAM each piece might need and be happy > > with. > > > > Otis > > -- > > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > - Original Message > > From: oleg_gnatovskiy <[EMAIL PROTECTED]> > > To: solr-user@lucene.apache.org > > Sent: Wednesday, April 16, 2008 2:05:23 PM > > Subject: Re: too many queries? > > > > > > Hello. I am having a similar problem as the OP. I see that you > recommended > > setting 4GB for the index, and 2 for Solr. How do I allocate memory for > > the > > index? I was under the impression that Solr did not support a RAMIndex. > > > > > > Walter Underwood wrote: > >> > >> Do it. 32-bit OS's went out of style five years ago in server-land. > >> > >> I would start with 8GB of RAM. 4GB for your index, 2 for Solr, 1 for > >> the OS and 1 for other processes. That might be tight. 12GB would > >> be a lot better. > >> > >> wunder > >> > >> On 4/16/08 7:50 AM, "Jonathan Ariel" <[EMAIL PROTECTED]> wrote: > >> > >>> In order to do that I have to change to a 64 bits OS so I can have > more > >>> than > >>> 4 GB of RAM.Is there any way to see how long does it takes to Solr to > >>> warmup > >>> the searcher? > >>> > >>> On Wed, Apr 16, 2008 at 11:40 AM, Walter Underwood > >>> <[EMAIL PROTECTED]> > >>> wrote: > >>> > A commit every two minutes means that the Solr caches are flushed > before they even start to stabilize. Two things to try: > > * commit less often, 5 minutes or 10 minutes > * have enough RAM that your entire index can fit in OS file buffers > > wunder > > On 4/16/08 6:27 AM, "Jonathan Ariel" <[EMAIL PROTECTED]> wrote: > > > So I counted the number if distinct values that I have for each > field > that I > > want a facet on. In total it's around 100,000. I tried with a > filterCache > > of 120,000 but it seems like too much because the server went down. > I > will > > try with less, around 75,000 and let you know. > > > > How do you to partition the data to a static set and a dynamic set, > > and > then > > combining them at query time? Do you have a link to read about that? > > > > > > > > On Tue, Apr 15, 2008 at 7:21 PM, Mike Klaas <[EMAIL PROTECTED]> > wrote: > > > >> On 15-Apr-08, at 5:38 AM, Jonathan Ariel wrote: > >> > >>> My index is 4GB on disk. My servers has 8 GB of RAM each (the OS > is > >>> 32 > >>> bits). > >>> It is optimized twice a day, it takes around 15 minutes to > optimize. > >>> The index is updated (commits) every two minutes. There are > between > >>> 10 > >>> and > >>> 100 inserts/updates every 2 minutes. > >>> > >> > >> Caching could help--you should definitely start there. > >> > >> The commit every 2 minutes could end up being an unsurmountable > problem. > >> You may have to partition your data into a large, mostly static > set > and a > >> small dynamic set, combining the results at query time. > >> > >> -Mike > >> > > > >> > >> > >> > > > > -- > > View this message in context: > > http://www.nabble.com/too-many-queries--tp16690870p16727264.html > > Sent from the Solr - User mailing list archive at Nabble.com. > > > > > > > > > > > > > > -- > View this message in context: > http://www.nabble.com/too-many-queries--tp16690870p16732932.html > Sent from the Solr - User mailing list archive at Nabble.com. > >
CorruptIndexException
Greetings all, We are using Solr to index Marc records to create a better, more user friendly library catalog here at the University of Virginia. To do this I have written a program starting from the VuFind Java importer written by Wayne Graham (from the College of William & Mary). After making extensive changes to accomodate our different indexing scheme the program was working great. Subsequently I upgraded to lucene version 2.3.1 to realize the faster indexing performance, and although it is faster, is also seems somewhat unreliable. A half a dozen times I have completely wiped out the existing index and started afresh, building an new index. Each time at some point in the indexing run I receive the Error message: Exception in thread "Thread-10" org.apache.lucene.index.MergePolicy$MergeException: org.apache.lucene.index.CorruptIndexException: doc counts differ for segment _3gh: fieldsReader shows 15999 but segmentInfo shows 16000 at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:271) Caused by: org.apache.lucene.index.CorruptIndexException: doc counts differ for segment _3gh: fieldsReader shows 15999 but segmentInfo shows 16000 at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:313) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:262) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:221) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3099) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:2834) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:240) This occurs a dozen or so times within the set of Marc records it is processing, and when the next segment starts processing I receive this message: Loading properties from import.properties Apr 16, 2008 7:03:51 AM org.apache.solr.core.Config setInstanceDir INFO: Solr home set to '/usr/local/projects/solr/' Apr 16, 2008 7:03:51 AM org.apache.solr.core.SolrConfig initConfig INFO: Loaded SolrConfig: solrconfig.xml Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore INFO: Opening new SolrCore at /usr/local/projects/solr/, dataDir=/usr/local/projects/solr/data Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: Reading Solr Schema Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: Schema name=solr_int Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: default search field is text Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: query parser default operator is AND Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: unique key field: id Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore parseListener INFO: Searching for listeners: //[EMAIL PROTECTED]"firstSearcher"] Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore parseListener INFO: Searching for listeners: //[EMAIL PROTECTED]"newSearcher"] Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore initWriters INFO: adding queryResponseWriter xslt=org.apache.solr.request.XSLTResponseWriter Apr 16, 2008 7:03:52 AM org.apache.solr.request.XSLTResponseWriter init INFO: xsltCacheLifetimeSeconds=5 Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: standard=solr.StandardRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: partitioned=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: dismax=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: catalog=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: music=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: semester_at_sea=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding lazy requestHandler: spellchecker=solr.SpellCheckerRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: /update=solr.XmlUpdateRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding lazy requestHandler: /update/csv=solr.CSVRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: /admin/luke=org.apache.solr.handler.admin.LukeRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding
possible highlighter limits?
Hi all, when we retrieve larger documents through SOLR with highlighting, the highlighted document gets truncated. We run the following query: http://172.16.9.67:8983/solr/select?indent=on&version=2.2&q=nid%3A13048+AND+body%3Afrance&start=0&rows=10&fl=*%2Cscore&qt=standard&wt=standard&explainOther=&hl=on&hl.fl=body&hl.fragsize=-1 which results in the truncated highlighting result. we are wondering if there is some hard limit in the highlighter? something we overlooked? any help and/or pointers would be greatly appreciated. thanks, Martijn
Re: XSLT transform before update?
Shalin Shekhar Mangar wrote: Hi Daniel, Maybe if you can give us a sample of how your XML looks like, we can suggest how to use SOLR-469 (Data Import Handler) to index it. Most of the use-cases we have yet encountered are solvable using the XPathEntityProcessor in DataImportHandler without using XSLT, for details look at http://wiki.apache.org/solr/DataImportHandler#head-e68aa93c9ca7b8d261cede2bf1d6110ab1725476 I think even if it is possible to use SOLR-469 for my needs, I'd still prefer the XSLT approach, because it's going to be a bit of configuration either way, and I'd rather it be an XSLT stylesheet than solrconfig.xml. In addition, I haven't yet decided whether I want to apply any patches to the version that we will deploy, but if I do go down the route of the XSLT transform patch, if I end up having to back it out the amount of work that it would be for me to do the transform at the XML source would be negligible, where it would be quite a bit of work ahead of me to go from using the DataImportHandler to not using it at all. Because both the solr instance and the XML source are in house, I have the ability to apply the XSLT at the source instead of at solr. However, there are different teams of people that control the XML source and solr, so it would require a bit more office coordination to do it on the backend. The data is a filemaker XML export (DTD fmresultset) and it looks roughly like this: 125 Ford Foundation ... Y5-A John Smith Y5-B Jane Doe I'm taking the product of the resultset and the relatedset, using both IDs concatenated as a unique identifier, like so: 125Y5-A Ford Foundation John Smith 125Y5-B Ford Foundation Jane Doe I can do the transform pretty simply with XSLT. I suppose it is possible to get the DataImportHandler to do this, but I'm not yet convinced that it's easier. Daniel
Updating in Solr.SOLR-139
Hi! There are any option to update a field (or a set of fields) of a document indexed in Solr,without having to update all the fields of the entire document??? I have seen the SOLR-139 patch,but I do not know what is the proper syntax of the command (or the xml to post) to update the document.Is required an additional tag in the schema.xml describing the updatable property??? For example: Please,I hope any suggestion!!! What is the xml required for the updating???For example,something like this: SOLR1000 9 Regards.. -- View this message in context: http://www.nabble.com/Updating-in-Solr.SOLR-139-tp16744841p16744841.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: CorruptIndexException
Which exact version of the JRE are you using? Can you try running java with -Xbatch (forces up front compilation)? Your situation sounds very similar to this one: http://lucene.markmail.org/message/awkkunr7j24nh4qj Mike On Apr 17, 2008, at 10:57 AM, Robert Haschart wrote: Greetings all, We are using Solr to index Marc records to create a better, more user friendly library catalog here at the University of Virginia. To do this I have written a program starting from the VuFind Java importer written by Wayne Graham (from the College of William & Mary). After making extensive changes to accomodate our different indexing scheme the program was working great. Subsequently I upgraded to lucene version 2.3.1 to realize the faster indexing performance, and although it is faster, is also seems somewhat unreliable. A half a dozen times I have completely wiped out the existing index and started afresh, building an new index. Each time at some point in the indexing run I receive the Error message: Exception in thread "Thread-10" org.apache.lucene.index.MergePolicy $MergeException: org.apache.lucene.index.CorruptIndexException: doc counts differ for segment _3gh: fieldsReader shows 15999 but segmentInfo shows 16000 at org.apache.lucene.index.ConcurrentMergeScheduler $MergeThread.run(ConcurrentMergeScheduler.java:271) Caused by: org.apache.lucene.index.CorruptIndexException: doc counts differ for segment _3gh: fieldsReader shows 15999 but segmentInfo shows 16000 at org.apache.lucene.index.SegmentReader.initialize (SegmentReader.java:313) at org.apache.lucene.index.SegmentReader.get (SegmentReader.java:262) at org.apache.lucene.index.SegmentReader.get (SegmentReader.java:221) at org.apache.lucene.index.IndexWriter.mergeMiddle (IndexWriter.java:3099) at org.apache.lucene.index.IndexWriter.merge (IndexWriter.java:2834) at org.apache.lucene.index.ConcurrentMergeScheduler $MergeThread.run(ConcurrentMergeScheduler.java:240) This occurs a dozen or so times within the set of Marc records it is processing, and when the next segment starts processing I receive this message: Loading properties from import.properties Apr 16, 2008 7:03:51 AM org.apache.solr.core.Config setInstanceDir INFO: Solr home set to '/usr/local/projects/solr/' Apr 16, 2008 7:03:51 AM org.apache.solr.core.SolrConfig initConfig INFO: Loaded SolrConfig: solrconfig.xml Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore INFO: Opening new SolrCore at /usr/local/projects/solr/, dataDir=/ usr/local/projects/solr/data Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: Reading Solr Schema Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: Schema name=solr_int Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: default search field is text Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: query parser default operator is AND Apr 16, 2008 7:03:52 AM org.apache.solr.schema.IndexSchema readConfig INFO: unique key field: id Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore parseListener INFO: Searching for listeners: //[EMAIL PROTECTED]"firstSearcher"] Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore parseListener INFO: Searching for listeners: //[EMAIL PROTECTED]"newSearcher"] Apr 16, 2008 7:03:52 AM org.apache.solr.core.SolrCore initWriters INFO: adding queryResponseWriter xslt=org.apache.solr.request.XSLTResponseWriter Apr 16, 2008 7:03:52 AM org.apache.solr.request.XSLTResponseWriter init INFO: xsltCacheLifetimeSeconds=5 Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: standard=solr.StandardRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: partitioned=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: dismax=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: catalog=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: music=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: semester_at_sea=solr.DisMaxRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding lazy requestHandler: spellchecker=solr.SpellCheckerRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding requestHandler: /update=solr.XmlUpdateRequestHandler Apr 16, 2008 7:03:52 AM org.apache.solr.core.RequestHandlers initHandlersFromConfig INFO: adding lazy req
ODD Solr Error on Update POST - XMLStreamException: ParseError
Hey All, I've been beating my head on this problem with no luck on finding the cause. I've done many nabble and google searches with no real solution. Let me explain the problem. First my system setup: Ubuntu 64bit Linux 6.06 Java 1.6 (amd64) (Also tried 1.5 with same results) Solr 1.2 (also tryed 1.3-dev with same results) Tomcat 6.0.16 (10 gigs of memory allocated) (also trying 5.5 with same results) Now the problem. When posting larger size documents, I am getting very random errors. I can hit refresh on the page, and the error will change on me. Here are some of those errors. The first error is the most common one, althought the second one does come up too. javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: Content is not allowed in prolog. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) at org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148) at org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) at org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) AND javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,8191] Message: XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) at org.apache.solr.handler.XmlUpdateRequestHandler.readDoc(XmlUpdateRequestHandler.java:318) at org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:195) at org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) at org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) The document I'm trying to post looks like this: k-690kohler K-690 kohler Single Hole Single Handle Pullout Spray High Arch Kitchen Faucet From The Vinnata Series. vinnata false false true false true 10186 2007-08-17T00:00:00Z K-690-BX 087206975028 493.02 493.02 493.02 179.78 493.02 493.02 493.02 493.02 416.66 688.79 493.02 467.56 Brazen Bronze Brazen Bronze bronze tones Bronze Tones true K-690-BV 087206769863 493.0
Tomcat JNDI and CWD Configuration problem with multiple solrs
Hello List! I am not an expert at configuring Tomcat, so I must be doing something wrong, but for the life of me, I cannot find anything that would explain this: I want to have two separate solr apps running on one tomcat. I use the exact configuration suggested here: http://wiki.apache.org/solr/SolrTomcat#head-024d7e11209030f1dbcac9974e55106abae837ac - Under multiple solr webapps. The apps seem to work fine, only for some reason, when I start tomcat it creates a solr dir in the cwd. So naturally, depending on where i do the restart, it wont work. If i cd to some dir where I have write access, the apps goes up fine, and it even says the solr/home is where it should be. (The dir i defined in the xml file, NOT cwd). But under statistics, both separate solr apps seems to use an IndexReader under CWD. Ideally I would want to be able to configure this, so I know where the reader keeps its files. And must both apps share this directory? I suspect this sharing is why I cannot reindex both apps at the same time, since it touches some .lock file during reindexing in the reader dir. I use the exact same xml files under /Catalina/localhost/solr1.xml etc as the wiki says. Same behaviour in tomcat 5.5 that ships with Ubuntu 7.10 and my own install of tomcat 6. (Although I dont understand why the example has "f:/" stuff in the directory paths, since that notation throws errors at me. Does anyone know if I am doing something wrong, and how I can have separate IndexReader folders? Albert
Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
Since you've already tried different Solr versions and different JVM versions, it's most likely Tomcat... try version 5.5. If that doesn't work, try a different OS (less likely, but it could be a libc bug or something). -Yonik On Thu, Apr 17, 2008 at 3:28 PM, realw5 <[EMAIL PROTECTED]> wrote: > > Hey All, > > I've been beating my head on this problem with no luck on finding the cause. > I've done many nabble and google searches with no real solution. Let me > explain the problem. First my system setup: > > Ubuntu 64bit Linux 6.06 > Java 1.6 (amd64) (Also tried 1.5 with same results) > Solr 1.2 (also tryed 1.3-dev with same results) > Tomcat 6.0.16 (10 gigs of memory allocated) (also trying 5.5 with same > results) > > Now the problem. When posting larger size documents, I am getting very > random errors. I can hit refresh on the page, and the error will change on > me. Here are some of those errors. The first error is the most common one, > althought the second one does come up too. > > javax.xml.stream.XMLStreamException: ParseError at > [row,col]:[1,1] Message: Content is not allowed in prolog. at > > com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) > at > > org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148) > at > > org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) > at > org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at > javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) > at java.lang.Thread.run(Thread.java:619) > > AND > > javax.xml.stream.XMLStreamException: ParseError at > [row,col]:[2,8191] Message: XML document structures must start and end > within the same entity. at > > com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) > at > > org.apache.solr.handler.XmlUpdateRequestHandler.readDoc(XmlUpdateRequestHandler.java:318) > at > > org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:195) > at > > org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) > at > org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at > javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) >
Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
Ok, so I tried tomcat 5.5, still not go. It might be helpful to note, that when I decrease the size of the post (take fields out) I can get it to post without error. It seems like it's barfing on a certain file size (buffer issue maybe??). I'm running 32-bit Ubuntu on our production system and have never seen these errors. Is it possible libc has a bug only in 64-bit Ubuntu? Lastly, I can try another OS...do you have any recommendations for a good 64-bit linux flavor? The below two errors still come up: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,10] Message: The markup in the document following the root element must be well-formed. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) at org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148) at org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) at org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) and javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: Content is not allowed in prolog. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) at org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148) at org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) at org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) Yonik Seeley wrote: > > Since you've already tried different Solr versions and different JVM > versions, it's most likely Tomcat... try version 5.5. If that doesn't > work, try a different OS (less likely, but it could be a libc bug or > s
Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
On Thu, Apr 17, 2008 at 5:41 PM, realw5 <[EMAIL PROTECTED]> wrote: > Ok, so I tried tomcat 5.5, still not go. It might be helpful to note, that > when I decrease the size of the post (take fields out) I can get it to post > without error. It seems like it's barfing on a certain file size (buffer > issue maybe??). I'm running 32-bit Ubuntu on our production system and have > never seen these errors. Is it possible libc has a bug only in 64-bit > Ubuntu? > > Lastly, I can try another OS...do you have any recommendations for a good > 64-bit linux flavor? Whatever you are comfortable with... if you don't already have something lying around, perhaps the latest ubuntu beta (8.04) Also double-check that you are sending exactly what you think you are. If you haven't already, capture the XML you are sending to a file, then use curl (the same version on the same box) to send the file to both the server that works and the one that doesn't. -Yonik
Re: possible highlighter limits?
On 17-Apr-08, at 8:05 AM, Martijn Dekkers wrote: Hi all, when we retrieve larger documents through SOLR with highlighting, the highlighted document gets truncated. We run the following query: http://172.16.9.67:8983/solr/select?indent=on&version=2.2&q=nid%3A13048+AND+body%3Afrance&start=0&rows=10&fl=*%2Cscore&qt=standard&wt=standard&explainOther=&hl=on&hl.fl=body&hl.fragsize=-1 which results in the truncated highlighting result. we are wondering if there is some hard limit in the highlighter? something we overlooked? See http://wiki.apache.org/solr/HighlightingParameters , particularly "hl.maxAnalyzedChars". -Mike
Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
The XML parser is probably not threadsafe but is being reused concurrently by multiple post threads resulting in these exceptions. The observed 'randomness' of the errors would be due to the unpredictable nature of the race condition between threads. The reason you don't see this with smaller documents would be that the likelihood of contention on small documents is reduced because the race is eliminated. This would also be generally independent of JVM, OS, memory allocation, etc as it seems to be. I would look into how these classes/methods are dealing with the parser factory. (keeping a static copy maybe?) org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148) org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) This seems to me to be the most likely culprit given what I've seen so far on this thread. I hope it helps. -- Brian - Original Message From: Yonik Seeley <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Thursday, April 17, 2008 3:28:08 PM Subject: Re: ODD Solr Error on Update POST - XMLStreamException: ParseError On Thu, Apr 17, 2008 at 5:41 PM, realw5 <[EMAIL PROTECTED]> wrote: > Ok, so I tried tomcat 5.5, still not go. It might be helpful to note, that > when I decrease the size of the post (take fields out) I can get it to post > without error. It seems like it's barfing on a certain file size (buffer > issue maybe??). I'm running 32-bit Ubuntu on our production system and have > never seen these errors. Is it possible libc has a bug only in 64-bit > Ubuntu? > > Lastly, I can try another OS...do you have any recommendations for a good > 64-bit linux flavor? Whatever you are comfortable with... if you don't already have something lying around, perhaps the latest ubuntu beta (8.04) Also double-check that you are sending exactly what you think you are. If you haven't already, capture the XML you are sending to a file, then use curl (the same version on the same box) to send the file to both the server that works and the one that doesn't. -Yonik
Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
On Thu, Apr 17, 2008 at 8:12 PM, Brian Johnson <[EMAIL PROTECTED]> wrote:
> The XML parser is probably not threadsafe but is being reused concurrently by
> multiple post threads resulting in these exceptions.
Hmmm, yes, the factory is reused... here's the code we use to try and
make it thread-safe:
@Override
public void init(NamedList args)
{
super.init(args);
inputFactory = BaseXMLInputFactory.newInstance();
try {
// The java 1.6 bundled stax parser (sjsxp) does not currently
have a thread-safe
// XMLInputFactory, as that implementation tries to cache and reuse the
// XMLStreamReader. Setting the parser-specific
"reuse-instance" property to false
// prevents this.
// All other known open-source stax parsers (and the bea ref impl)
// have thread-safe factories.
inputFactory.setProperty("reuse-instance", Boolean.FALSE);
}
catch( IllegalArgumentException ex ) {
// Other implementations will likely throw this exception since
"reuse-instance"
// isimplementation specific.
log.fine( "Unable to set the 'reuse-instance' property for the
input factory: "+inputFactory );
}
}
Dan: are you sending updates with multiple threads? If so, can you
just try a single one at a time?
-Yonik
> The observed 'randomness' of the errors would be due to the unpredictable
> nature of the race condition between threads. The reason you don't see this
> with smaller documents would be that the likelihood of contention on small
> documents is reduced because the race is eliminated. This would also be
> generally independent of JVM, OS, memory allocation, etc as it seems to be.
>
> I would look into how these classes/methods are dealing with the parser
> factory. (keeping a static copy maybe?)
>
>
>
> org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148)
>
> org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386)
>
> org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65)
>
> This seems to me to be the most likely culprit given what I've seen so far
> on this thread. I hope it helps.
>
> -- Brian
>
>
>
> - Original Message
> From: Yonik Seeley <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent: Thursday, April 17, 2008 3:28:08 PM
> Subject: Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
>
> On Thu, Apr 17, 2008 at 5:41 PM, realw5 <[EMAIL PROTECTED]> wrote:
> > Ok, so I tried tomcat 5.5, still not go. It might be helpful to note, that
> > when I decrease the size of the post (take fields out) I can get it to
> post
> > without error. It seems like it's barfing on a certain file size (buffer
> > issue maybe??). I'm running 32-bit Ubuntu on our production system and
> have
> > never seen these errors. Is it possible libc has a bug only in 64-bit
> > Ubuntu?
> >
> > Lastly, I can try another OS...do you have any recommendations for a good
> > 64-bit linux flavor?
>
> Whatever you are comfortable with... if you don't already have
> something lying around, perhaps the latest ubuntu beta (8.04)
>
> Also double-check that you are sending exactly what you think you are.
> If you haven't already, capture the XML you are sending to a file,
> then use curl (the same version on the same box) to send the file to
> both the server that works and the one that doesn't.
>
> -Yonik
>
>
>
>
Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
OK. So, I just freshly formated my dev box. Reinstalled Ubuntu 6.06 LTS (amd64), Java 6 (64bit), Tomcat 6.0.16 (with URIEncoding="UTF-8"), and installed solr-1.2.0. I'm still getting the same weird errors, but they have changed a little bit. Below are the errors that are return as I hit refresh. It appears that the error message is slightly differnet every refresh, "...start tag and not XXX"... xxx changes between letters numbers and other random characters. Also attached is the document I'm posting. I've posted this doc both from coldfusion and curl (both are not multi-threaded). It will occasionally post WITHOUT error. Although it's still random. What I've concluded is, this only happens with a large post, if your only posting a few feilds it returns succesful. Let me know if I can provide any other details and I'll be happy. Thanks Yonik! Dan POSTING: k-12182kohler K-12182 kohler Single Hole Single Handle Lavatory Faucet From The Fairfax Collection. fairfax false false true false true 8102Fairfax® single-control lavatory faucet with lever handle
2007-07-31T00:00:00Z K-12182 -BV 087206576935 197.05 197.05 197.05 75.79 197.05 197.05 197.05 197.05 167.49 272.83 197.05 187.2 Brushed Bronze Brushed Bronze bronze tones Bronze Tones true K-12182-G 20087206537831 134.91 K-12182 -BV 087206576935 197.05 197.05 197.05 75.79 197.05 197.05 197.05 197.05 167.49 272.83 197.05 187.2 Brushed Bronze Brushed Bronze bronze tones Bronze Tones true K-12182-G 20087206537831 134.91 K-12182 -BV 087206576935 197.05 197.05 197.05 75.79 197.05 197.05 197.05 197.05 167.49 272.83 197.05 187.2 Brushed Bronze Brushed Bronze bronze tones Bronze Tones true K-12182-G 20087206537831 134.91 K-12182 -BV 087206576935 197.05 197.05 197.05 75.79 197.05 197.05 197.05 197.05 167.49 272.83 197.05 187.2 Brushed Bronze Brushed Bronze bronze to
The Fairfax faucet collection blends classic style with ease of operation. The graceful curves of this single-control faucet create a timeless appeal appropriate for any installation, from powder room to master bath. KOHLER washerless ceramic disc valves exceed industry longevity standards two times, so you can enjoy years of reliable performance. A high-temperature limit stop helps to prevent scalding.- Premium material construction for durability and reliability
- KOHLER finishes resist corrosion and tarnishing, exceeding industry durability standards over two times
- Flexible stainless steel supplies simplify installation
- Completes Fairfax design solution with Kohler accessories.
- Low-flow aerator option available (please see latest price book)
Re: config for very frequent solr updates
Geoff, There was just another thread where the person said he was doing updates every 2 minutes. Like you said, with the way Solr warms searchers, this could be too frequent for instances with large caches and high autowarmCount. You may be better off playing with the combination of larger older index and a smaller index with updates kept in RAM (on the slave, of course). Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Geoffrey Young <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Thursday, April 17, 2008 8:28:09 AM Subject: config for very frequent solr updates hi all :) I didn't see any documentation on this, so I was wondering what the experience here was with updating solr with a small but constant trickle of daemon-style updates. unfortunately, it's a business requirement that backend db updates make it to search as the changes roll in (5 minutes is out of the question). with the way solr handles new searchers, warming, etc, I was wondering if anyone had experience with this kind of thing and could share thoughts/general config stuff on it. thanks. --Geoff
Re: Searching "inside of words"
Hi Daniel, Well, searching "inside of words" requires special treatment, because normally searches work on words/terms/tokens. Make use of the following: $ ff \*NGram\*java ./src/java/org/apache/solr/analysis/EdgeNGramTokenizerFactory.java ./src/java/org/apache/solr/analysis/NGramTokenizerFactory.java ./src/java/org/apache/solr/analysis/NGramFilterFactory.java ./src/java/org/apache/solr/analysis/EdgeNGramFilterFactory.java Use these to create a new field type make Solr tokenize and index your terms as, say, uni-grams. Instead (or in addition to) indexing "Termobyxa", index "T e r m o b y x a". Do the same with the query-time analyzer, and you'll be able to search within words. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Daniel Löfquist <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Thursday, April 17, 2008 5:46:15 AM Subject: Searching "inside of words" Hi, I'm still pretty new to Solr. We're using it for searching on our site right now though. The configuration is however pretty much based on the example-files that come with Solr and there's one type of search that I can't get to work. Each item has fields called "title" and "description", both of which are of type "text". The type "text" is defined like this in our schema.xml : My problem is that if I have an item with "title"="Termobyxa", a search for "Termo" gives me a hit but if I search for "ermo" or "byxa" I get no hit. How do I make it so that this kind of search "inside a word" returns a hit? Sincerely, Daniel Löfquist
how to get total hits for the request?
I'm using solr and unable to manage total number of document returned by search? how can i do this? -- View this message in context: http://www.nabble.com/how-to-get-total-hits-for-the-request--tp16760375p16760375.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: possible highlighter limits?
Mike, you are a saint! thanks - we actually had this defined, but somewhat wrongly: typo (hangs head in shame) Martijn On 18/04/2008, Mike Klaas <[EMAIL PROTECTED]> wrote: > > On 17-Apr-08, at 8:05 AM, Martijn Dekkers wrote: > > > Hi all, > > > > when we retrieve larger documents through SOLR with highlighting, the > > highlighted document gets truncated. We run the following query: > > > > > > http://172.16.9.67:8983/solr/select?indent=on&version=2.2&q=nid%3A13048+AND+body%3Afrance&start=0&rows=10&fl=*%2Cscore&qt=standard&wt=standard&explainOther=&hl=on&hl.fl=body&hl.fragsize=-1 > > > > which results in the truncated highlighting result. > > > > we are wondering if there is some hard limit in the highlighter? > > something > > we overlooked? > > > > See http://wiki.apache.org/solr/HighlightingParameters , particularly > "hl.maxAnalyzedChars". > > -Mike >
