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
