[
https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504164#comment-16504164
]
Shawn Heisey commented on SOLR-6734:
------------------------------------
One of the things that I would very much like to have is the ability in the
admin UI to change things like heap size and restart Solr. One of the
challenges around that is that the admin UI is part of Solr itself, so although
it would be straightforward for Solr to stop itself, there must be a mechanism
that starts Solr back up.
Another challenge is related to how process forking works. On Linux, and
probably other systems as well, when a process forks to spawn another process,
most aspects of the original process are inherited by the new process. One of
those aspects is memory allocation. So if we embed the daemon into Solr itself
and a new process is required, and Solr is allocating 8GB of memory from the
system, the new process will ALSO have 8GB of memory allocated. It would be
free to shed that memory, but it's my understanding that it would all be
allocated before the process would be able to drop it. On systems with limited
resources, this could be a serious problem. As much as it might sound like a
good idea, embedding the agent daemon into Solr isn't viable.
So here's an idea that I'm starting to like, independent from any sort of
cluster auto-discovery:
Let's install (up to) three services. One for Solr, one for the agent, and one
for ZK, for installs where an external ensemble is not provided. ZK would be
handled through a small wrapper Main class that incorporates whatever IPC we
settle on, whether it's a network socket on localhost or something else. Solr
and the agent would also include the same IPC capability. Because they're all
separate services, they can be started independently from each other. The
agent would be capable of stopping or starting the other two services.
The agent would have a very small heap, and might handle process control by
running system commands or included scripts. Not 100% sure about monitoring,
but some of it might be in the agent and some of it might be through external
scripts. The IPC capability in all three services can also serve as a monitor
point.
The agent would absorb SolrCLI functionality and handle complex control script
commands in a non-daemon mode, communicating with the services as required.
> Standalone solr as *two* applications -- Solr and a controlling agent
> ---------------------------------------------------------------------
>
> Key: SOLR-6734
> URL: https://issues.apache.org/jira/browse/SOLR-6734
> Project: Solr
> Issue Type: Sub-task
> Reporter: Shawn Heisey
> Priority: Major
>
> In a message to the dev list outlining reasons to switch from a webapp to a
> standalone app, Mark Miller included the idea of making Solr into two
> applications, rather than just one. There would be Solr itself, and an agent
> to control Solr.
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
