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

Alan Woodward commented on SOLR-5473:
-------------------------------------

I think part of the reason this is so unwieldy is that ClusterState itself is 
monolithic - you call ZkStateReader.getClusterState() and it goes and gets the 
state of the entire cluster, and then you typically only need information for a 
single collection.  So ClusterState needs to know about all the different state 
versions, which bloats it up, and then leaves you with API warts like 
ZkController being responsible for removing watches.

What I think should really happen here is that we should add an intermediate 
layer, CollectionState.  This has three implementations, one that is a 
singleton watching the master clusterstate.json, one that is a separate object 
with watchers for each 'external' collection, one that just directly fetches 
data from ZK whenever it's queried.  When ZkStateReader starts up (and can we 
maybe move createClusterStateWatchersAndUpdate() into the constructor?) it 
works out which CollectionState type it needs for each collection in the 
cluster.  Users of the API just call ZkStateReader.getCollection() and they get 
the right kind of CollectionState object, no need to have external knowledge of 
what the state version of the collection is.

Having stuck my oar in here, I'm now going offline for a couple of weeks :-)  
Maybe this API change should be a separate issue, but I think it should be 
nailed down before this one is committed.


> Split clusterstate.json per collection and watch states selectively 
> --------------------------------------------------------------------
>
>                 Key: SOLR-5473
>                 URL: https://issues.apache.org/jira/browse/SOLR-5473
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>             Fix For: 5.0
>
>         Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
> SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
> SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log
>
>
> As defined in the parent issue, store the states of each collection under 
> /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to