Custom Query (420 matches)

client-gli.app required debugging. But .app shortcuts run without a console. Long ago, Dr Bainbridge had already found out how to redirect stdout and stderr to a log file from a .app.

START

exec 2>/tmp/gli.output

printenv 1>&2

/Volumes/Research/ak19_2/GS3bin_23Sep2014/gli/client-gli.sh

END

Adding this in to all the .app shortcuts we have, after trying to write to :

START

logdir=/tmp

if test -n $GSDLHOME; then

if test -w $GSDLHOME/logs; then

logdir=$GSDLHOME/logs

fi

fi

exec 2>$logdir/gli.output

&2 echo "GSDLHOME is |$GSDLHOME|"

printenv 1>&2

/Volumes/Research/ak19_2/GS3bin_23Sep2014/gli/client-gli.sh

END

Replacing all references to $GSDLHOME with @gsdl3srchome@ for GS3

This ticket has been added in to document the actual code tested in the automator, since in the .app files it ends up html encoding angle brackets and ampersand signs.

Running solr with GS3 server removes cores at ant stop preventing sucessful Jetty server start

Running the Jetty server runs the local solr web interface. We use this to test new things we can try to do with solr. I think we can run the jetty server only when the GS3 server is stopped.

The buildcol process also runs the jetty server to ingest documents.

When we run the GS3 server and do a search in a solr collection, it adds cores to the file web/ext/solr/solr.xml. If we then stop the GS3 server, the cores are removed again from solr.xml. We can't successfully run the jetty server at this point, since it can't find the cores in solr.xml and we have to re-run the buildcol process on the collection to get them back.

However, if we run the GS3 server and stop it again immediately, the cores remain in the solr.xml file. At this point, we can run the jetty server.

What seems to be happening is a symmetric loading of solr cores on startup, and unloading of cores on stopping the GS3 server. See SolrSearch.java, configure() and cleanup() methods. The symmetry makes sense, but we need to investigate whether it is really necessary to remove the solr cores on shutdown, since this is what is preventing us from running the jetty server whenever we want. Does any part of the solr-related code, including activate.pl, actually require that the solr cores be removed? Start by looking at activate.pl, ext/solr/perllib/solrserver.pm, GS3 src code's gsdl3/service/SolrSearch.java

Changesets:

+ Perl - gs3/bin/script

http://trac.greenstone.org/changeset/28780

http://trac.greenstone.org/changeset/28798

http://trac.greenstone.org/changeset/29008

+ C++ - gs2/runtime-src/src/recpt/formatconverter.cpp, formattools.cpp and .h

http://trac.greenstone.org/changeset/28760

http://trac.greenstone.org/changeset/28761

http://trac.greenstone.org/changeset/28960

+ Java GLI - especially gatherer/gui/FormatConversionDialog.java and especially gatherer/gui/NumberedJTextArea.java

http://trac.greenstone.org/changeset/28995

http://trac.greenstone.org/changeset/29001

http://trac.greenstone.org/changeset/29006

http://trac.greenstone.org/changeset/29007 (gs3/bin/tidyconfig.cfg used by HTMLTidy when used by GLI FormatConversionDialog)

http://trac.greenstone.org/changeset/29009

http://trac.greenstone.org/changeset/29011

http://trac.greenstone.org/changeset/29012

http://trac.greenstone.org/changeset/29016

http://trac.greenstone.org/changeset/29017

http://trac.greenstone.org/changeset/29030

http://trac.greenstone.org/changeset/29031

http://trac.greenstone.org/changeset/29034

(http://trac.greenstone.org/changeset/29036

http://trac.greenstone.org/changeset/29037)

+ GS3/web/interfaces/default/transform/config_format.xsl

http://trac.greenstone.org/changeset/29035