Indeed, that worked very well. We've gone beyond that now to a local build of GSearch's Solr module that ignores the local index. This effectively disables GSearch's ability to search. We don't mind this, because we are querying Solr by other means (Blacklight).
Thanks very much! Are there plans to rewrite the FgsSolr module to use the Solr Web interface for searching in future? --- A. Soroka Digital Research and Scholarship R & D the University of Virginia Library On May 14, 2009, at 9:48 AM, Gert Schmeltz Pedersen wrote: > 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 ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
