lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <>
Subject [jira] [Commented] (SOLR-6734) Standalone solr as *two* applications -- Solr and a controlling agent
Date Mon, 21 May 2018 06:19:00 GMT


Shawn Heisey commented on SOLR-6734:

[], I do not know if I'm having trouble parsing what you're saying because
it's late and I'm exhausted, or if I'm experiencing a fundamental disconnect.

Let me try to give you a 30000-foot view of control script operation in the new world I'm
envisioning.  I'm going to describe a posix platform here, but for Windows, the general idea
would be similar.

 * If running as a service, somehow get the service name.  Lots of options for exactly how
this is done.
 * The first primary job of the control script will be locating Java using whatever mechanisms
make sense.  Once it's found, run a little Java class whose entire job is looking at the vendor,
version, and other characteristics of the JVM and the operating system.  If the found JVM
version has known issues, or if configurations are found that could be problematic, it would
display a message alerting the user to those problems.  The exit code of that program could
be used to configure workarounds or abort script operation.
 * Use the service name if present to look somewhere central, such as /etc/solr/servicename.
 Otherwise look somewhere in the extracted directory structure, possibly $INSTALL_DIR/etc.
 Find the primary config there.  Start the agent with the primary config and the service name.
 * The agent will be responsible for starting Solr using the information in the primary config.
 Solr will be responsible for loading the secondary config, either from ZK or the same location
as the primary config.  The secondary config would be a likely location for defining the solr
home and similar settings.  Then Solr would start the indexes.
 * In this brave new world, we no longer have solr.xml.  Its functionality would be handled
by the secondary config.

The control script will hand off to the agent or SolrCLI for much of its functionality.  It
will be much less complex than before, so the differences between shell and batch languages
won't be as much of a burden.

When there are installed services, there should be something written in the install directory
so that running bin/solr manually can know that services have been installed.  If there's
only one installed service, it should use that for its operation, with an optional CLI parameter
to ignore services.  If multiple services are installed and nothing was provided to indicate
which service to use, the script should end early with a message describing how to tell it
which service to talk to or how to ignore services.

Having a Solr-specific plugin for systems like Kubernetes does sound like a good idea, but
it should be reliant on our control infrastructure, not the other way around.

I would like us to have a Windows service installer in addition to the shell script for other
platforms.  That will require research and experimentation.

> Standalone solr as *two* applications -- Solr and a controlling agent
> ---------------------------------------------------------------------
>                 Key: SOLR-6734
>                 URL:
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Shawn Heisey
>            Priority: Major
> In a message to the dev list outlining reasons to switch from a webapp to a standalone
app, Mark Miller included the idea of making Solr into two applications, rather than just
one.  There would be Solr itself, and an agent to control Solr.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message