Shawn Heisey commented on SOLR-9635:

User Customization:

I think we should go with Java properties files for user customizations.  Only 
when we reach the core config and the schema should we switch to a structured 
format (currently XML, possibly moving to JSON).

With a little bit of thought and work, it should be possible to provide the 
user with several layers of property configuration.  here are the properties 
filenames I can imagine:

service.properties:  At the root of the install directory.  Would contain 
things currently handled in solr.in.sh and solr.xml.  Accessible in structured 
config as $\{solr.service.XXX\}.  Might want to replace "service" with 

cloud.properties: At the root of the zookeeper tree.  In addition to 
configuring settings for the whole cloud, would be accessible as 
$\{solr.cloud.XXX\}.  In conjunction with service.properties, might replace 

collection.properties: In the collection path in zookeeper.  In addition to 
providing collection settings, would be accessible as $\{solr.collection.XXX\}.

core.properties: No real change here.  Still accessible as $\{solr.core.XXX\}.

This would be an ideal time to implement the service breadcrumbs idea I have 
mentioned previously.  A /etc/default/solr.properties file could be 
added/modified by the service install script and have simple mappings of 
service name to install directory, where service.properties would fill in the 
rest of the blanks.

> Implement Solr as two java processes -- one process to manage the other.
> ------------------------------------------------------------------------
>                 Key: SOLR-9635
>                 URL: https://issues.apache.org/jira/browse/SOLR-9635
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Shawn Heisey
> One idea that Mark Miller mentioned some time ago that I really like is the 
> idea of implementing Solr as two java processes, with one managing the other.
> When I think about this idea, what I imagine is a manager process with a 
> *very* small heap (I'm thinking single-digit megabytes) that is responsible 
> for starting a separate Solr process with configured values for many 
> different options, which would include the heap size.
> Basically, the manager process would replace most of bin/solr as we know it, 
> would be able to restart a crashed Solr, and the admin UI could have options 
> for changing heap size, restarting Solr, and other things that are currently 
> impossible.  It is likely that this idea would absorb or replace the SolrCLI 
> class.
> Initially, I intend this issue for discussion, and if the idea looks 
> workable, then we can work towards implementation.  There are plenty of 
> bikesheds to paint as we work the details.  I have some preliminary ideas 
> about some parts of it, which I will discuss in comments.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to