You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2018/05/21 06:21:00 UTC
[jira] [Comment Edited] (SOLR-6734) Standalone solr as *two*
applications -- Solr and a controlling agent
[ https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482225#comment-16482225 ]
Shawn Heisey edited comment on SOLR-6734 at 5/21/18 6:20 AM:
-------------------------------------------------------------
[~markrmiller@gmail.com], 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 at startup time 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.
was (Author: elyograg):
[~markrmiller@gmail.com], 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org