[
https://issues.apache.org/jira/browse/SOLR-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989052#comment-15989052
]
Shawn Heisey commented on SOLR-9635:
------------------------------------
Been a while since I thought about this issue. I've had some new ideas.
What if we move the admin UI from the main Solr process to the manager process,
on a different port than Solr itself? In standalone mode, the UI would manage
the Solr process that the manager is controlling, but in cloud mode, it could
manage the entire cloud.
This manager code could also manage a standalone ZooKeeper process independent
of any Solr process it was also managing.
Thinking about the "master node" idea mentioned by [~otis] on the solr-user
list, I'm also imagining a situation where someone could deploy one node with
the manager, managing a ZK process (and maybe a Solr process), then deploy
additional nodes, pointing them at the host/port of the first manager process,
to fully automate the process of setting up multi-node SolrCloud and ZK. Once
that first node were set up, the admin UI could be used to change what runs on
each node that's in the cloud, change the cluster and ZK configuration, etc.
We would need to think about upgrades, for the manager process itself, Solr,
and ZK.
> 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.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
