[
https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482225#comment-16482225
]
Shawn Heisey commented on SOLR-6734:
------------------------------------
[[email protected]], 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: https://issues.apache.org/jira/browse/SOLR-6734
> 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.
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
