[
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057659#comment-14057659
]
Mark Miller edited comment on SOLR-5473 at 7/10/14 4:50 PM:
------------------------------------------------------------
bq. ClusterState has no reference to ZkStateReader.
+1 on that part, but it doesn't seem to address much else, so I don't have too
much to say.
{quote}
All changes will be visible realtime. The point is nodes NEVER cache any states
(only Solrj does SOLR-5474). .nodes watch collections where it is a member.
Other states are always fetched just in time from ZK.
{quote}
It sounds like what I said is an issue? You can easily be on a node in your
cluster that doesn't have part of a collection. If you are using the admin UI
to view your cluster and a node from another collection goes down, will that
reflect on the solr admin UI you are using that doesn't host part of that
collection? I think this is a big deal if not, and nothing in the patch
addresses this kinds of issues for users or developers. You are telling me all
the behavior is the same? I don't believe that yet.
was (Author: markrmil...@gmail.com):
bq. ClusterState has no reference to ZkStateReader.
+1 on that part, but it doesn't seem to address much else, so I don't have too
much to say.
{quote}
All changes will be visible realtime. The point is nodes NEVER cache any states
(only Solrj does SOLR-5474). .nodes watch collections where it is a member.
Other states are always fetched just in time from ZK.
{quote}
It sounds like what I said is an issue? You can easily be on a node in your
cluster that doesn't have part of a collection. If you are using the admin UI
to view your cluster and node from another collection goes down, will that
reflect on the solr admin UI you are using that doesn't host part of that
cluster? I think this is a big deal if not, and nothing in the patch addresses
this kinds of issues for users or developers. You are telling me all the
behavior is the same? I don't believe that yet.
> 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_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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
