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 2018/06/05 13:22:00 UTC

[jira] [Commented] (SOLR-6734) Standalone solr as *two* applications -- Solr and a controlling agent

    [ https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501760#comment-16501760 ] 

Shawn Heisey commented on SOLR-6734:
------------------------------------

I've been thinking about how an agent might facilitate setting up a fault tolerant SolrCloud, complete with ZK servers.

Users would start out by running a command like "bin/solr cloudbuild start" on one node that has been installed as a service.  This would start or reconfigure the agent in a mode where it can begin communicating with other agents.  Then another command or set of commands would be run on that first node to set it up with necessary services for the cluster.

If multicast communication can be written in Java with relatively simple code, that would allow the agents to communicate with each other on LAN subnet and form a SolrCloud cluster without explicit address/hostname configuration.  If somebody got really ambitious and configured multicast routing, they could even do it on different subnets or across datacenters.

I envision using 239.89.83.0 as a default multicast address.  UDP port 8983 seems fitting to use as a default.  As each node is configured, with additional "bin/solr cloudbuild" commands, it will begin sending periodic status packets on the configured multicast group, which every node will listen to and build a whole picture of the cluster.

Once there are at least three nodes configured, another command, perhaps "bin/solr cloudbuild build", can be called.  If the overall cluster config passes validation, this will signal each node to write its configuration for ZK and Solr, start (or restart) the services, and turn off cloudbuild mode.  If everything goes well, the user will have a functional fault-tolerant SolrCloud install, without any need to worry about how to install ZK as a separate service.

I have most of this idea mapped out in my head at a high level.  It will require fleshing out to realize as usable code.


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org