Run Solr 4.7.2 as a servlet inside tomcat, instead of building solr col launching jetty server
|Reported by:||ak19||Owned by:||ak19|
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
Change History (7)
comment:1 by , 7 years ago
|Summary:||Running solr with GS3 server removes cores at ant stop preventing sucessful Jetty server start → Run Solr 4.7.2 as a servlet inside tomcat, instead of building solr col launching jetty server|