Differences between revisions 23 and 24
Revision 23 as of 2011-06-27 07:54:18
Size: 9939
Comment:
Revision 24 as of 2011-08-25 20:58:19
Size: 10145
Editor: c-24-23-118-38
Comment: The init.d script was wrong for jetty 6.x
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
Download the [[http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/trunk/jetty-distribution/src/main/resources/bin/jetty.sh|jetty.sh startup script]], and place it at /etc/init.d/jetty. On RedHat systems, uncomment the chkconfig lines and use chkconfig to add it to the boot sequence. Download the [[http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/trunk/jetty-distribution/src/main/resources/bin/jetty.sh|jetty.sh startup script]], and place it at /etc/init.d/jetty. On RedHat systems, uncomment the chkconfig lines and use chkconfig to add it to the boot sequence.  Note: if you are using an older Solr distribution that uses Jetty 6.x, you'll have to download this [[http://svn.codehaus.org/jetty/jetty/branches/jetty-6.1/bin/jetty.sh|jetty.sh startup script]] instead.

Solr with Jetty

  • Solr runs fine with Jetty, as illustrated by the solr/example application. See the instructions in the generic Solr installation page for basic setup info

  • For non-trivial installations, JettyPlus is recommended.

  • NOTE: Jetty currently does not accept URL-encoded unicode code points outside of the basic multilingual plane (> \uFFFF)

Init script to run the Solr example

This section describes how to to make the Solr example run automatically as a service on startup. It assumes that the Solr distribution is unpacked, and has been tested by running java -jar start.jar from the example directory.

Download the jetty.sh startup script, and place it at /etc/init.d/jetty. On RedHat systems, uncomment the chkconfig lines and use chkconfig to add it to the boot sequence. Note: if you are using an older Solr distribution that uses Jetty 6.x, you'll have to download this jetty.sh startup script instead.

Then create /etc/default/jetty, to configure the startup script. Assuming that the full Solr example (including start.jar) was placed in /opt/solr, the configuration would look something like this:

JAVA_HOME=/usr/java/default
JAVA_OPTIONS="-Dsolr.solr.home=/opt/solr/solr $JAVA_OPTIONS"
JETTY_HOME=/opt/solr
JETTY_USER=solr
JETTY_LOGS=/opt/solr/logs

All of these settings are important. In particular, not setting JETTY_LOGS would lead jetty to attempt (and fail) to place request logs in /home/solr/logs.

The start-up script expects jetty to redirect standard input and output to a log file. Therefore, create /opt/solr/etc/jetty-logging.xml with the following:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<!-- =============================================================== -->
<!-- Configure stderr and stdout to a Jetty rollover log file        -->
<!-- this configuration file should be used in combination with      -->
<!-- other configuration files.  e.g.                                -->
<!--    java -jar start.jar etc/jetty-logging.xml etc/jetty.xml      -->
<!-- =============================================================== -->
<Configure id="Server" class="org.mortbay.jetty.Server">

    <New id="ServerLog" class="java.io.PrintStream">
      <Arg>
        <New class="org.mortbay.util.RolloverFileOutputStream">
          <Arg><SystemProperty name="jetty.home" default="."/>/logs/yyyy_mm_dd.stderrout.log</Arg>
          <Arg type="boolean">false</Arg>
          <Arg type="int">90</Arg>
          <Arg><Call class="java.util.TimeZone" name="getTimeZone"><Arg>GMT</Arg></Call></Arg>
          <Get id="ServerLogName" name="datedFilename"/>
        </New>
      </Arg>
    </New>

    <Call class="org.mortbay.log.Log" name="info"><Arg>Redirecting stderr/stdout to <Ref id="ServerLogName"/></Arg></Call>
    <Call class="java.lang.System" name="setErr"><Arg><Ref id="ServerLog"/></Arg></Call>
    <Call class="java.lang.System" name="setOut"><Arg><Ref id="ServerLog"/></Arg></Call>

</Configure>

Logging

For information about controlling JDK Logging (aka: java.util logging) in Jetty please consult the Jetty docs... http://docs.codehaus.org/display/JETTY/Server+Log

Configuring Solr Home with JNDI

Jetty Plus provides an addEnvEntry for configuring the JNDI property needed to specify your Solr Home directory.

To do this, use an "addWebApplication" that looks something like this...

  <Call name="addWebApplication">
    <Arg>/solr/*</Arg>
    <Arg>/your/path/to/the/solr.war</Arg>
    <Set name="extractWAR">true</Set>
    <Set name="defaultsDescriptor">org/mortbay/jetty/servlet/webdefault.xml</Set>

    <Call name="addEnvEntry">
      <Arg>solr/home</Arg>
      <Arg type="String">/your/path/to/your/solr/home/dir</Arg>
    </Call>
  </Call>

Multiple Solr Webapps

Multiple Solr Webapps (pre-Jetty6)

Multiple solr instances can be run in a single Jetty Plus server by using multiple "addWebApplication" Call blocks with different values for the solr/home JNDI parameter...

  <Call name="addWebApplication">
    <Arg>/solr1/*</Arg>
    <Arg>/your/path/to/the/solr.war</Arg>
    <Set name="extractWAR">true</Set>
    <Set name="defaultsDescriptor">org/mortbay/jetty/servlet/webdefault.xml</Set>

    <Call name="addEnvEntry">
      <Arg>solr/home</Arg>
      <Arg type="String">/your/path/to/your/solr/home/dir</Arg>
    </Call>
  </Call>

  <Call name="addWebApplication">
    <Arg>/solr2/*</Arg>
    <Arg>/your/path/to/the/solr.war</Arg>
    <Set name="extractWAR">true</Set>
    <Set name="defaultsDescriptor">org/mortbay/jetty/servlet/webdefault.xml</Set>

    <Call name="addEnvEntry">
      <Arg>solr/home</Arg>
      <Arg type="String">/your/path/to/your/alternate/solr/home/dir</Arg>
    </Call>
  </Call>

Multiple Solr Webapps (Jetty6)

Jetty6 changed their context deployment syntax. Also, JNDI lookups, which are necessary for deploying multiple Solr instances require a special configuration. The default Jetty6 install does not include JNDI support, but it is easily tacked on. See this page: JettyJNDI

New jetty.xml syntax:

    <New  class="org.mortbay.jetty.webapp.WebAppContext">
        <Arg><Ref id="contexts"/></Arg>
        <Arg><SystemProperty name="jetty.home" default="."/>/webapps/solr_app_1</Arg>
        <Arg>/solr_app_1</Arg>
        <Set name="ConfigurationClasses"><Ref id="plusConfig"/></Set>
        <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>
        <New class="org.mortbay.jetty.plus.naming.EnvEntry">
            <Arg>solr/home</Arg>
            <Arg type="java.lang.String"><SystemProperty name="jetty.home" default="."/>/webapps/solr_app_1/solr</Arg>
        </New>
    </New>

Where the variable for solr/home points to a directory containing a conf directory that in turn has a solrconfig.xml file.

JNDI Caveats Noted By Users

(7/2007 MattKangas) The recipe above didn't work for me with Jetty 6.1.3. Specifying "solr/home" via "<New class="...EnvEntry">" sets a GLOBAL value which gets evaluated after the full configuration is read, so the last setting wins.

Fortunately, I've found a solution that works well:

  • Specify "ContextDeployer" in jetty.xml

  • For each web app, add a .xml file in "./contexts"

    • Set ConfigurationClasses to activate JNDI. (must be done separately for each webapp)

    • Set overrideDescriptor to define an override web.xml file

    • In the overrideDescriptor file, set an <env-entry> for "solr/home"

The "overrideDescriptor" settings will be applied AFTER it has been configured by the default descriptor and the WEB-INF/web.xml descriptor.

Alas, you still need the additional "Plus" .jars, and you need to define the "plusConfig" and set "ConfigurationClasses" appropriately. Without this, the overrideDescriptor won't be applied.

I'm glossing over a lot of details, so attached is a tarball with a known-good configuration that runs two Solr instances inside one Jetty container. I'm using Solr 1.2.0 and Jetty 6.1.3 respectively.

DEMO_multiple_webapps_jetty_6.1.3.tgz


(12/2008 KenEllinwood) I'm using Solr-1.3.0 and Jetty 6.1.12. Apparently the name for JNDI must have a leading slash now., eg., "solr/home" becomes "/solr/home" in the jetty config files. I was able to get the example up and running in a stand-alone Jetty without fiddling with the "overrideDescriptor" as described above. I'm using ContextDeployer in jetty.xml with the following context definition. Note the 3 argument syntax for the EnvEntry -- this appears to be a new requirement in more recent versions of Jetty. Also, I had to use an absolute path for the data directory in solrconfig.xml... not sure why.

<?xml version="1.0"  encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="contextPath">/solr</Set>
  <Set name="war">/home/ken/search/apache-solr-1.3.0/example/webapps/solr.war</Set>

  <Set name="extractWAR">true</Set>
  <Set name="copyWebDir">false</Set>
  <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>

  <Array id="plusConfig" type="java.lang.String">
    <Item>org.mortbay.jetty.webapp.WebInfConfiguration</Item>
    <Item>org.mortbay.jetty.plus.webapp.EnvConfiguration</Item>
    <Item>org.mortbay.jetty.plus.webapp.Configuration</Item>
    <Item>org.mortbay.jetty.webapp.JettyWebXmlConfiguration</Item>
    <Item>org.mortbay.jetty.webapp.TagLibConfiguration</Item>
  </Array>

  <Set name="ConfigurationClasses"><Ref id="plusConfig"/></Set>

  <New class="org.mortbay.jetty.plus.naming.EnvEntry">
    <Arg>/solr/home</Arg>
    <Arg type="java.lang.String">/home/ken/search/apache-solr-1.3.0/example/solr</Arg>
    <Arg type="java.lang.Boolean">true</Arg>
  </New>

</Configure>

Long HTTP GET Query URLs

If you're issuing very long HTTP GET queries to Solr, you may need to adjust the headerBufferSize parameter for your connector in jetty.xml. (See http://docs.codehaus.org/display/JETTY/Configuring+Connectors) The default for this parameter is 4K. If your buffer size is too small, the symptom client-side won't be an error message but rather having your HTTP connection closed without an HTTP response.

SolrJetty (last edited 2014-11-12 02:37:32 by 167)