[
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: [email protected]
For additional commands, e-mail: [email protected]
