How to install multicore Apache Solr on FreeBSD with Jetty
If you use Apache Solr with your Drupal site, you have probably
come across the need to have more than one Solr instance. You may have
multiple sites, or just multiple copies of the same site, production and
staging perhaps?
There are two widely published ways to accomplish that. One is to set up
completely separate Solr instances with whatever Java-server you’re
using. That is somewhat inefficient, and I was unable to get such a
setup working properly anyways. So here’s the alternative, “multi core”.
The benefit of using multi core is that you avoid most of the
configuration overhead associated with figuring out how to get multiple
WebAppContainerDeploymentContextFactoryGeneratorWidgetClass
instances
(or whatever they’re named in your brand of Java-server) to coexist by
using the same WAR-file but not the same configuration. I spent a lot of
hours trying to accomplish just that.
Instead, all the interesting stuff happens in the Solr configuration,
which is a lot less confusing for a Java novice like me.
Instructions
-
Install a Java JRE.
You may want to see my explanation on how to do this.
-
Install Jetty and Solr.
If you use
portmaster
, this can be as simple as runningportmaster www/jetty textproc/apache-solr
-
Create a folder for your Solr multi core instance’s configuration and
data files. This could be anywhere, but in this example, I’m going to
use/srv/solr
. -
Create a
/srv/solr/solr.xml
file for the configuration, setting up
the different cores into folders.Mine looks like this:
(solr.xml) download1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<span class="line"><span class="cp"><?xml version="1.0" encoding="UTF-8" ?></span></span><span class="line"><span class="c"><!—</span></span><span class="line"><span class="c">All (relative) paths are relative to the installation path</span></span><span class="line"><span class="c"> </span></span><span class="line"><span class="c"> persistent: Save changes made via the API to this file</span></span><span class="line"><span class="c"> sharedLib: path to a lib directory that will be shared across all cores</span></span><span class="line"><span class="c">—></span></span><span class="line"><span class="nt"><solr</span> <span class="na">persistent=</span><span class="s">"false"</span><span class="nt">></span></span><span class="line"></span><span class="line"> <span class="c"><!—</span></span><span class="line"><span class="c"> adminPath: RequestHandler path to manage cores. </span></span><span class="line"><span class="c"> If 'null' (or absent), cores will not be manageable via request handler</span></span><span class="line"><span class="c"> —></span></span><span class="line"> <span class="nt"><cores</span> <span class="na">adminPath=</span><span class="s">"/admin/cores"</span> <span class="na">sharedLib=</span><span class="s">"lib"</span><span class="nt">></span></span><span class="line"> <span class="nt"><core</span> <span class="na">name=</span><span class="s">"dev"</span> <span class="na">instanceDir=</span><span class="s">"dev"</span> <span class="nt">/></span></span><span class="line"> <span class="nt"><core</span> <span class="na">name=</span><span class="s">"prod"</span> <span class="na">instanceDir=</span><span class="s">"prod"</span> <span class="nt">/></span></span><span class="line"> <span class="nt"><core</span> <span class="na">name=</span><span class="s">"stg"</span> <span class="na">instanceDir=</span><span class="s">"stg"</span> <span class="nt">/></span></span><span class="line"> <span class="nt"></cores></span></span><span class="line"><span class="nt"></solr></span></span>
-
Create all the folders referenced in the config file.
We specified four folders, so lets create them via a simple
mkdir dev lib prod stg
(while standing in the/srv/solr
folder). -
Make these folders owned by the user that will run our Solr
instances. In this example, I’ll use thewww
account, but it would
be more secure to set up a separate account for running Solr if you
have other web servers running on the same machine.chown www:www dev lib prod stg
-
For each core you want to set up, copy or symlink the schema and
other configuration files you need into the conf folder in each core
folder. In this example, I’m copying the example configuration from
/usr/local/share/examples/apache-solr/solr/conf/
. If you’re working
with Drupal, be sure to copy the solr configuration it ships with
into each core.mkdir prod/conf
cd prod/conf
cp -r /usr/local/share/examples/apache-solr/solr/conf/* ./
cd ../..
cp -r prod/conf dev/
cp -r prod/conf stg/
-
Enable Jetty
In this example, we’re going to use Jetty to run the Solr
service. I am not well versed in the Java lingo for this, but Jetty
is a servlet container, so I guess that means Solr is being run as a
servlet. I also tried this with Tomcat, but that was a lot harder to
configure properly.Add
jetty_enable="YES"
on a new line in/etc/rc.conf
. -
Copy
/usr/local/jetty/etc/jetty.xml
to/usr/local/etc
. -
Symlink
solr.war
into/usr/local/jetty/webapps
cd /usr/local/jetty/webapps
ln -s /usr/local/share/java/classes/apache-solr-3.2.0.war solr.war
- Symlink
/srv/solr
into/usr/local/jetty
cd /usr/local/jetty
ln -s /srv/solr
- Start Jetty by running
service jetty start
Hopefully, after all this work, Solr should be ready once its done
booting up.
You can check that it’s working by running
curl -iL localhost:8080/solr/prod/admin/
. This should output the HTML
for the admin interface.
If you have problems, try running tail -f /usr/local/jetty/jetty.log
in one terminal, and then service jetty restart
in another, and look
what goes on as Jetty restart (there’ll be a lot of messages flying by,
but the error should be in there somewhere).