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
