Hello,
We have a new project to use Solr. Our Solr instance will use Jetty
rather than Tomcat. We plan to extend the Solr core system by adding
additional classes (jar files) to the
/opt/solr/server/solr-webapp/webapp/WEB-INF/lib directory to extend
features. We also plan to run two instances of Solr on each physical
server preferably from a single installed Solr instance. I've read the
best practices doc on running two Solr instances, and while it's
detailed about how to set up two instances, it doesn't cover our
specific use case.
For ease of our custom jar deployments, we would prefer to have only one
install of Solr. However, I have read that the JVM's default class
loader provides lazy class loading. This means that should we replace a
jar file (during new release deployments) and the JVM goes looking for
the old jar after replacement, the JVM could crash and dump. Is lazy
class loading a concern with Solr and specifically when custom built
jars are used?
Would it be better to use two separate installs of Solr and manage each
independently or can we safely get away with using a single Solr install
and then update jars in this instance for both running instances? I'm
trying to find the best safety practices for release deployment with the
way we intend to install and use our Solr in our environment. I should
also mention that running Solr instances cannot be down concurrently due
to cluster sharding.
Is there any other way through CLASSPATH or other config/runtime methods
where we could use a single install, but separate the WEB-INF directory
into two to support each separate running instance? Are there any other
ideas?
Any advice is appreciated.
Thanks.
--
Signature
*Brian Wright*
*Sr. Systems Engineer *
901 Mariners Island Blvd Suite 200
San Mateo, CA 94404 USA
*Email *bri...@marketo.com <mailto:bri...@marketo.com>
*Phone *+1.650.539.3530**
*****www.marketo.com <http://www.marketo.com/>*
Marketo Logo
