[
https://issues.apache.org/jira/browse/SOLR-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569115#comment-15569115
]
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
"instance".
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
solr.xml.
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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
