[jira] [Updated] (SOLR-3617) Consider adding start scripts.

["Timothy Potter (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Potter updated SOLR-3617:
---------------------------------

    Attachment: SOLR-3617.patch

Here's a rough cut of a *nix start/stop script. I'm posting early to get some feedback before going too far down this path if it's not what we want.

First, I think the start/stop script should go hand-in-hand / complement any work done on SOLR-3619 and SOLR-3259, which is why I chose to put the script in the {{$SOLR_TIP/bin}} vs. {{example/bin}} (where SOLR_TIP is the root directory where Solr is installed). One of the nice ideas in SOLR-3619 is to have a "server" directory for production environments and use the example dir only for running examples.

You can do: {{solr -help}} or {{solr <command> -help}}, such as {{solr start -help}} to see usage. 

Here's an overview of some of the features in this script, which I'll demonstrate by showing example usages:

{{solr}}  Prints usage and exits

{{solr -f}}  Starts the example server in the foreground; alternatively, we could support a -b option to background the server if we want foreground to be the default behavior.

{{solr -i}}  Looks for running Solr servers and prints information about any that are found. Right now, the script is doing a GET to the /admin/system/info handler, which is too verbose so we need a synopsis option (I'll open another ticket)

{{solr -p 8984}}  Starts Solr in the background bound to port 8984

{{solr -cloud}} or {{solr -c}}  Starts Solr in "solrcloud" mode in the background on port 8983; since a zkHost is not provided, this will also set the -DzkRun option to start the embedded ZooKeeper on port 9983. Or you could pass -z to set the zkHost param.

{{solr -e <example>}}, such as {{solr -e dih}} Starts the specified example server such as the DIH example server

{{solr -f -c -p 8985 -m 1g}}  Would start Solr in solrcloud mode in the foreground bound to port 8985 with max heap set to 1 gig (i.e.  -Xms1g -Xmx1g)

I think you get the idea ... here's the full usage for the start command:

{noformat}
Usage: solr start [-f] [-c] [-h hostname] [-p port] [-d directory] [-z zkHost] [-m memory] [-e example]

  -f            Start Solr in foreground; default starts Solr in the background
                  and sends stdout / stderr to solr-PORT-console.log

  -c            Start Solr in SolrCloud mode; if -z not supplied, an embedded ZooKeeper
                  instance is started; -cloud or --cloud are synonyms for -c

  -h <host>     Specify the hostname for this Solr instance

  -p <port>     Specify the port to start the Solr HTTP listener on; default is 8983

  -d <dir>      Specify the Solr server directory; defaults to example

  -z <zkHost>   ZooKeeper connection string; only used when running in SolrCloud mode using -c

  -m <memory>   Sets the min (-Xms) and max (-Xmx) heap size for the JVM, such as: -m 4g
                  results in: -Xms4g -Xmx4g; by default, this script sets the heap size to 512m

  -e <example>  Name of the example to run; available examples:
      cloud:         SolrCloud example
      default:       Solr default example
      dih:           Data Import Handler
      schemaless:    Schema-less example
      multicore:     Multicore
{noformat}

The stop behavior is pretty basic, but it does try to stop the Jetty server gracefully before issuing kill commands using the Jetty stop key / port.

Notice that I'm not supporting a {{restart}} command yet but that's easy to add if we don't like the current behavior of stopping a running server first before starting, i.e. in the current impl, if you do: {{solr start && solr start}} (just for illustration purposes), the second start invocation will stop the server and then start it back up. Alternatively, we could easily have the script check if a server is already running and complain, thus forcing the user to stop first or issue a "restart".

I've also included support for sourcing env variables from an include file named {{solr.in.sh}} (similar to how Cassandra's start script works). The idea here is that for production environments, users will likely want to keep common settings like Java memory options and zkHost in an include file and then only use command-line options to set machine specific values, such as the host (-h). The script searches common paths for the include file.

I'm still sorting out how to support the multiple nodes for the SolrCloud example. Currently, the script will start both nodes and index the documents as shown in the ref guide, but there's more that could be done with this example. For now, to run the cloud example, do: 

{{solr -e cloud}}

which sets up the node1 and node2 directories, starts the servers on ports 8983 and 7574 respectively, and then indexes the docs in mem.xml and monitor2.xml

There are also some other goodies in here which may or may not cause some folks heartburn. For instance, I find it really helpful to enable the RMI options to allow you to attach a tool like VisualVM to the JVM hosting Solr. It's enabled by default here but can be disabled by setting {{ENABLE_REMOTE_JMX_OPTS="false"}}

Also, I've built-in Shawn H's famous GC tuning options for Solr, which I've found to be good for many Solr workflows. In general, I think the start script should take as much of the thinking out of running Solr as possible, which includes baking in best practices.

So far I've only tested this on Mac and RedHat but should work on other flavors of Linux.

> Consider adding start scripts.
> ------------------------------
>
>                 Key: SOLR-3617
>                 URL: https://issues.apache.org/jira/browse/SOLR-3617
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Mark Miller
>         Attachments: SOLR-3617.patch
>
>
> I've always found that starting Solr with java -jar start.jar is a little odd if you are not a java guy, but I think there are bigger pros than looking less odd in shipping some start scripts.
> Not only do you get a cleaner start command:
> sh solr.sh or solr.bat or something
> But you also can do a couple other little nice things:
> * it becomes fairly obvious for a new casual user to see how to start the system without reading doc.
> * you can make the working dir the location of the script - this lets you call the start script from another dir and still have all the relative dir setup work.
> * have an out of the box place to save startup params like -Xmx.
> * we could have multiple start scripts - say solr-dev.sh that logged to the console and default to sys default for RAM - and also solr-prod which was fully configured for logging, pegged Xms and Xmx at some larger value (1GB?) etc.
> You would still of course be able to make the java cmd directly - and that is probably what you would do when it's time to run as a service - but these could be good starter scripts to get people on the right track and improve the initial user experience.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org