[
https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482034#comment-16482034
]
Shawn Heisey commented on SOLR-6734:
------------------------------------
Here's an attempt to solidify some things:
* I like the socket idea. Here's some things that I think the agent will need
if we choose sockets for IPC:
** A port number. Solr port minus 500 as the default, maybe?
** Socket command to stop Solr.
** Socket command to start Solr.
** Socket command to get Solr status.
** Possibly similar operations for ZK.
** Socket command to stop itself (and any managed processes).
* I think the agent should use SolrJ jars (and dependencies). Mostly for
monitoring.
* The control script will only start/stop Solr indirectly. It will be
responsible for making sure the agent is running or stopped as required.
* The other things the control script does (creating cores/collections, etc)
probably do not need adjustment. After making sure the agent and its
controlled processes are running, those operations would continue to be handled
through SolrCLI.
* If basic new-style configurations aren't found, then operations with the
control script will fail fast. If old configurations are found, then the
output should reference instructions for config conversion. Conversion should
be easy and automated, but always initiated manually so the user knows what is
being done.
Whats below might belong on SOLR-6733, but dovetails with the above thoughts,
so I'm putting it here:
Probably the simplest way to handle agent configuration is a properties file,
but if we load everything needed for SolrJ, we will have noggit. I'm really
liking the notion of using one format for ALL Solr config files, and I think
json has the most going for it in that goal. It can do almost as much as XML.
The files are smaller than XML and easier for a newbie to grasp. I see that
noggit supports comments, so that eliminates the one significant drawback that
I see with the official json standard compared to other formats.
Given the ubiquitous nature of properties files, I am not opposed to their use
for things where the configuration is simple, even if we settle on another
format like json as a standard. Particularly where a user wanting typical
operation will never need to worry about them -- which describes
core.properties.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
