You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2016/10/12 15:50:20 UTC
[jira] [Commented] (SOLR-9635) Implement Solr as two java processes
-- one process to manage the other.
[ https://issues.apache.org/jira/browse/SOLR-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569088#comment-15569088 ]
Shawn Heisey commented on SOLR-9635:
------------------------------------
Inter-Process Communication:
I would prefer a strictly local communication method, not TCP. The ideas that come to mind are sockets and named pipes ... but I haven't yet researched available options in Java. A cross-platform option is best.
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org