Yes, the browseIndex page is not automatically modified during configuration,
if you change the indexName from fgsIndex to something else. You have to change
the SELECT element in your runtime
webapps/fedoragsearch/WEB-INF/classes/fgsconfigFinal/rest/adminBrowseIndexToHtml.xslt
from
<option
value="fgsIndex">fgsIndex</option>
to
<option
value="">default</option>
The message "fgsIndex is not configured" is local to the browseIndex operation
and due to the above option element. It is not due to the indexDir setting.
The indexDir setting must be the path to the solr index.
Thank you for pointing to unclear or incomplete configuration instructions.
Gert
On 16/12/2013, at 20.48, Peri Stracchino wrote:
> ok, thanks Gert
>
> Took your advice and tried reconfiguring from scratch, but I'm still
> struggling a bit here.
>
> The browseIndex reports that the fgsIndex is not configured.
> In my fgsconfig-basic.properties I have my indexBase set to
> localhost:8080/solr, and my indexDir set to
> /opt/york/digilib/solr-3.6.1/data/index. The name of my gsearch index is
> YODL, as below
>
> namesOfIndexes=YODL
> # FgsIndex: indexBase is the server base url, in case of Solr or Zebra.
> #indexBase=http://localhost:8983/solr
> indexBase=http://localhost:8080/solr
>
> # FgsIndex: indexDir is the path to the index.
> indexDir=${local.FEDORA_HOME}/gsearch/FgsIndex
> indexDir=/opt/york/digilib/solr-3.6.1/data/index
>
> should the indexDir configuration point to the solr/data/index, or to the
> fedoragsearch/WEB-INF/classes/fgsconfigFinal/index/YODL?
>
> I'v tried both, pointing to the solr index seems more correct but results in
> the "fgsIndex is not configured." message, however pointing to the index
> within gsearch seems wrong becauser then I get a message about missing
> segments, so it is surely expecting the solr index. So what is the further
> configuration of the fgsIndex that I need to do?
>
> tearing my hair out somewhat :-(
> Peri
>
>
>
>
>
> On 16 December 2013 10:42, Gert Schmeltz Pedersen <gerts...@gmail.com> wrote:
> You should create a complete fgsconfigFinal/* using the procedure given in
> GSearch 2.5 instead of reusing the old xslts.
>
> Also make sure that you include the field named PID as the unique key in your
> runtime schema.xml for solr, see the three comments marked "For GSearch 2.5"
> in schema-3.6.1-for-fgs-2.5.xml.
>
> Gert
>
>
> On 16/12/2013, at 10.45, Peri Stracchino wrote:
>
>> if i run updateFromPid i get Mon Dec 16 08:54:19 GMT 2013 Connection error
>> (is Solr running at http://yodlapp1.york.ac.uk/solr/update ?):
>> java.io.IOException: Server returned HTTP response code: 400 for URL:
>> http://yodlapp1.york.ac.uk/solr/update.
>> However solr is definately running on this url (its running on tomcat, which
>> is being proxied by apache webserver), I'm assuming this error is being
>> produced because its not actually getting documents to update in the format
>> it expects. If I index a non foxml object using the solr post tool ,
>> fedoragsearch will find this object when I use browseIndex using *:* as the
>> start term.
>>
>>
>> This is an example of one of the warnings:
>>
>> SEVERE: org.apache.solr.common.SolrException: ERROR: [doc=york:11269] cannot
>> set an index-time boost, norms are omitted for field PID: york:11269
>> at
>> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:252)
>> at
>> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:60)
>> at
>> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115)
>> at
>> org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:157)
>> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
>> at
>> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:58)
>> at
>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
>> at
>> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365)
>> at
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260)
>> 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:191)
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>> 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:293)
>> at
>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>> at
>> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
>> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
>> at
>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
>> at
>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
>> at
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>> at java.lang.Thread.run(Thread.java:679)
>>
>>
>>
>> at the end of my fedoragsearch.daily.log I have the following, which also
>> suggests to me that there is some further stylesheet editing needed all
>> these stylesheets were the ones I was using with solr 1.4, but I wonder if I
>> now need to make some changes to one or more of them - the one we use for
>> our transformation is solr-yodl-gsearch2v1.xslt, but is it possible that I
>> need to edit some other files to make it work with solr 3.6.1?
>>
>> "DEBUG 2013-12-12 12:46:47,657 (Config) config created
>> configName=fgsconfigFinal errors=
>> DEBUG 2013-12-12 12:46:47,657 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/copyXml.xslt
>> DEBUG 2013-12-12 12:46:48,291 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoGfindObjectsToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,564 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoUpdateIndexToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,598 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoBrowseIndexToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,641 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoGetRepositoryInfoToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,659 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoGetIndexInfoToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,678 (Config) insertSystemProperties
>> propertyValue=/opt/york/digilib/fedora/data/objects
>> DEBUG 2013-12-12 12:46:48,678 (Config) checkStylesheet for
>> /fgsconfigFinal/repository/YODL/copyXml.xslt
>> DEBUG 2013-12-12 12:46:48,692 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/solr-yodl-gsearch2v1.xslt
>> DEBUG 2013-12-12 12:46:49,061 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/updateIndexToResultPage.xslt
>> DEBUG 2013-12-12 12:46:49,066 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/gfindObjectsToResultPage.xslt
>> DEBUG 2013-12-12 12:46:49,072 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/browseIndexToResultPage.xslt
>> DEBUG 2013-12-12 12:46:49,077 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/copyXml.xslt
>> DEBUG 2013-12-12 12:46:49,080 (Config) insertSystemProperties
>> propertyValue=/opt/york/digilib/solr-3.6.1/data/index
>> DEBUG 2013-12-12 12:46:49,080 (Config) checkAnalyzerClass
>> analyzerClassName=org.apache.lucene.analysis.standard.StandardAnalyzer
>> "
>>
>>
>> On 13 December 2013 21:19, Gert Schmeltz Pedersen <gerts...@gmail.com> wrote:
>> Hi Peri
>>
>> What do the warnings say?
>>
>> What happens if you updateIndex fromPid?
>>
>> Gert
>>
>>
>> On 13/12/2013, at 19.42, Peri Stracchino wrote:
>>
>> > Hi
>> > We've been running fedoragsearch 2.5 for quite a while against solr 1.4.
>> > We want to upgrade it to run against solr 3.6.1.
>> > Now my solr 3.6.1 installation seems to be working ok - I can post and
>> > index the demonstration xml files. I can also see these files if I go to
>> > gsearch browseIndex and give *:* as my start term, so its obviously
>> > looking in the right place for the index.
>> >
>> > But its not working properly against my new solr yet, because when I try
>> > to update index from foxml files, it runs then finishes with no documents
>> > indexed, just warnings
>> >
>> > I'v changed SOLR_HOME to the new solr
>> > I have copied the schema.xml and solrconfig.xml from <SOLR_HOME>/conf into
>> > fedoragsearch/WEB-INF/classes/fgsconfigFinal/<our index name>/conf. the
>> > foxml to solr indexing format xslt transformation document we were using
>> > with the old solr version is still present.
>> > fgsindex.indexBase = http://<our server address>/solr
>> > fgsindex.indexBase =<oursolr_home>/data/index
>> >
>> > It must surely be looking in the right place for the foxml files, because
>> > 1) the fedora installation hasnt changed, and 2) its reporting an
>> > appropriate number of warnings, given the number of objects in the system
>> > and that each one has apparently failed. If I run uopdate index create
>> > empty it makes the usual request to manualy stop solr, clear the index and
>> > restart solr, when I run updateindex from foxml it initially starts
>> > without complaint - its only when it finishes that it emerges that nothing
>> > has actually indexed
>> >
>> > Is there some critical gsearch reconfiguration step I'v missed out, or can
>> > anyone suggest any useful way I can diagnose whats going wrong? I suspect
>> > perhaps there is something in the foxml files - or the output produced by
>> > the transformation script - which conflicts with the schema.xml - it this
>> > seems like the most likely scenario then I'll continue testing this line
>> > by line, but I'm concerned I may be looking in the wrong direction
>> >
>> > any pointers would be much appreciated!
>> >
>> > Peri
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Rapidly troubleshoot problems before they affect your business. Most IT
>> > organizations don't have a clear picture of how application performance
>> > affects their revenue. With AppDynamics, you get 100% visibility into your
>> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> > Pro!
>> > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
>> > Fedora-commons-users mailing list
>> > Fedora-commons-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Fedora-commons-users mailing list
>> Fedora-commons-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
>> Fedora-commons-users mailing list
>> Fedora-commons-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Fedora-commons-users mailing list
> Fedora-commons-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> Fedora-commons-users mailing list
> Fedora-commons-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
