[
https://issues.apache.org/jira/browse/SOLR-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569131#comment-15569131
]
Shawn Heisey commented on SOLR-9635:
------------------------------------
I realize that what I've written above assumes that one install directory only
handles one Solr service, and that currently it is possible to run multiple
services out of one directory. I personally prefer one service per install
directory, but I'm guessing that this might need modifying. Perhaps
service.properties can become service.XXX.properties, where XXX is the service
name, and the file would most commonly be named service.solr.properties.
> 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]
