[
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]