Mailing-List: contact solr-commits-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Thu, 18 Aug 2011 16:39:28 -0000
Message-ID: <20110818163928.8765.5071@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSolr_Wiki=5D_Update_of_=22NewSolrCloudDesign=22_by_YonikSeel?=
 =?utf-8?q?ey?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for chan=
ge notification.

The "NewSolrCloudDesign" page has been changed by YonikSeeley:
http://wiki.apache.org/solr/NewSolrCloudDesign?action=3Ddiff&rev1=3D7&rev2=
=3D8

Comment:
alternative to cluster lock

   * Multiple schema support ?  Should we just remove it from ver 1.0 for s=
implicity?
   * solr.xml .  Is there a need at all for this in the cloud mode?
  =

+ =3D=3D Alternative to a Cluster Lock =3D=3D
+ It may be simpler to have a coordinator node (we avoid the term master si=
nce that is associated with traditional index replication) that is establis=
hed via leader election.
+ Following a pattern of treating the zookeeper state as the "truth" and ha=
ving nodes react to changes in that state allow for more future flexibility=
 (such as allowing an external management tool directly change the zookeepe=
r state to control the cluster).  Having a coordinator (as opposed to grabb=
ing a lock every time) can be more scalable too.  A hybrid model where a cl=
uster lock is used only in certain circumstances can also make sense.
+=20