You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2014/07/10 18:52:05 UTC
[jira] [Comment Edited] (SOLR-5473) Split clusterstate.json per
collection and watch states selectively
[ 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: markrmiller@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org