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

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

Reply via email to