I think you can get over this problem, if you put a copy of an initial (empty) index at the local dummy location given at fgsindex.indexDir, let me hear, if that works.
-Gert -----Original Message----- From: ajs6f [mailto:[email protected]] Sent: 14. maj 2009 15:29 To: [email protected] Cc: Bess Sadler Subject: Re: [Fedora-commons-users] GSearch with remote SOLR instance? That's sounds fantastic, because that's exactly what we want to do (we're providing discovery from that index in other ways). But we've been having some problems doing exactly that. For the parameter in GSearch config as follows: #fgsindex.indexDir = <...> The directory must exist, it is used for browseIndex and gfindObjects we found that we couldn't get GSearch running if we didn't provide a value and if we did provide a (dummy) value, then when we try an updateIndex fromPid operation from the REST interface, we get an exception thrown as I enclose after this message. It seems that GSearch is trying to access the (dummy) index even though it should be able simply to ignore it. I also enclose our index.properties (further below). We much appreciate any help on this problem. Is the proper procedure to omit the parameter entirely, or is there some other "switch" to be thrown? Should I be expecting to tinker with dk.defxws.fgssolr.OperationsImpl.updateIndex()? --- A. Soroka Digital Research and Scholarship R & D the University of Virginia Library dk.defxws.fedoragsearch.server.errors.GenericSearchException: IndexReader open error indexName=SolrPowr : ; nested exception is: java.io.FileNotFoundException: no segments* file found in org.apache.lucene.store.FSDirectory@/var/lib/tomcat6/webapps/gsearch/ WEB-INF/classes/config/index/SolrPowr/example/solr/data/index: files: at dk.defxws.fgssolr.OperationsImpl.getIndexReader(OperationsImpl.java:631) at dk.defxws.fgssolr.OperationsImpl.updateIndex(OperationsImpl.java: 252) at dk .defxws .fedoragsearch .server.GenericOperationsImpl.updateIndex(GenericOperationsImpl.java: 308) at dk.defxws.fedoragsearch.server.RESTImpl.updateIndex(RESTImpl.java: 261) at dk.defxws.fedoragsearch.server.RESTImpl.doGet(RESTImpl.java:114) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org .apache .catalina .core .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 290) 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: 191) 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: 845) 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) Caused by: java.io.FileNotFoundException: no segments* file found in org.apache.lucene.store.FSDirectory@/var/lib/tomcat6/webapps/gsearch/ WEB-INF/classes/config/index/SolrPowr/example/solr/data/index: files: at org.apache.lucene.index.SegmentInfos $FindSegmentsFile.run(SegmentInfos.java:604) at org .apache .lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:111) at org.apache.lucene.index.IndexReader.open(IndexReader.java:316) at org.apache.lucene.index.IndexReader.open(IndexReader.java:206) at dk.defxws.fgssolr.OperationsImpl.getIndexReader(OperationsImpl.java:627) ... 18 more # Properties for the SolrPowr index fgsindex.indexName = SolrPowr fgsindex.operationsImpl = dk.defxws.fgssolr.OperationsImpl fgsindex.defaultUpdateIndexDocXslt = demoFoxmlToSolr fgsindex.defaultUpdateIndexResultXslt = updateIndexToResultPage fgsindex.defaultGfindObjectsResultXslt = gfindObjectsToResultPage fgsindex.defaultBrowseIndexResultXslt = browseIndexToResultPage fgsindex.defaultGetIndexInfoResultXslt = copyXml #fgsindex.indexBase = http://localhost:8983/solr # the Solr server base url fgsindex.indexBase = http://solrpowr.lib.virginia.edu:8984/solr #fgsindex.indexDir = <...> The directory must exist, it is used for browseIndex and gfindObjects fgsindex.indexDir = /usr/share/tomcat6/webapps/gsearch/WEB-INF/ classes/config/index/SolrPowr/example/solr/data/index # the next two properties have their counterpart in the Solr config file schema.xml, # make sure they match, else you get different search behaviour from the same query # sent to Solr versus sent to GSearch. fgsindex.analyzer = org.apache.lucene.analysis.standard.StandardAnalyzer fgsindex.defaultQueryFields = dc.description dc.title On May 14, 2009, at 5:40 AM, Gert Schmeltz Pedersen wrote: > You are right that GSearch updateIndex sends Solr Add documents, > where the index location in GSearch config is not used, but it is > used by gfindObjects and by browseIndex. You may not want to use > these two GSearch operations, because you can search directly on > Solr, and then the index location is not used at all. > > Best, > Gert > > -----Original Message----- > From: ajs6f [mailto:[email protected]] > Sent: 12. maj 2009 15:15 > To: [email protected] > Subject: [Fedora-commons-users] GSearch with remote SOLR instance? > > We're setting up GSearch against a 3.1 repository, and we'd like to > connect it to a SOLR instance that is running on a different machine. > (Fedora and GSearch on one machine, SOLR on another.) > > We're wondering how to go about doing that. The sticking point seems > to be the deamdn in GSearch config for a filesystem location for the > SOLR index. If GSearch is emitting SOLR Add documents to manipulate > the indexes, it's not clear to us why GSearch would want that > location... we've checked mailing list archives and GSearch documents, > but can find no mention of how to do this. Is it possible? > > --- > A. Soroka > Digital Research and Scholarship R & D > the University of Virginia Library > > > > > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! > Your > production scanning environment may not be a perfect world - but > thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Fedora-commons-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
