lucene-dev mailing list archives

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

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message