[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447711#comment-13447711
]
Mark Miller edited comment on SOLR-3785 at 9/5/12 1:14 AM:
-----------------------------------------------------------
bq. I guess in my version (revision 1355667) of the code, ZkStateReader is not
even watching /collections/<collection-name>/leaders/. It is watching
/live_nodes/.
The overseer watches /leaders I believe - and publishes results to the
clusterstate.json.
bq. But I guess what you are telling me is, that even though ZkStateReader was
watching /collections/<collection-name>/leaders/ it might not be notified that
the leader has gone unless there is another one taking over?
Only as of a few days go. The next candidate to take over immediately publishes
a null leader which clears it from clusterstate.json
bq. Did you change it so that /collections/<collection-name>/leaders/ is
watched? So that only thing left is to make sure the leader-marker is removed
even if there is no other to take over.
It's already watched by the Overseer. The change is to make the Overseer remove
leaders from ClusterState.json the same way it adds them.
was (Author: [email protected]):
bq.
I guess in my version (revision 1355667) of the code, ZkStateReader is not even
watching /collections/<collection-name>/leaders/. It is watching /live_nodes/.
The overseer watches leader I believe - and publishes results to the
clusterstate.json.
bq. But I guess what you are telling me is, that even though ZkStateReader was
watching /collections/<collection-name>/leaders/ it might not be notified that
the leader has gone unless there is another one taking over?
Only as of a few days go. The next candidate to take over immediately publishes
a null leader which clears it from clusterstate.json
bq. Did you change it so that /collections/<collection-name>/leaders/ is
watched? So that only thing left is to make sure the leader-marker is removed
even if there is no other to take over.
It's already watched by the Overseer. The change is to make the Overseer remove
leaders from ClusterState.json the same way it adds them.
> Cluster-state inconsistent
> --------------------------
>
> Key: SOLR-3785
> URL: https://issues.apache.org/jira/browse/SOLR-3785
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.0
> Environment: Self-build Solr release built on Apache Solr revision
> 1355667 from 4.x branch
> Reporter: Per Steffensen
>
> Information in CloudSolrServer.getZkStateReader().getCloudState() (called
> cloudState below) seems to be inconsistent.
> I have a Solr running the leader of slice "sliceName" in collection
> "collectionName" - no replica to take over. I shut down this Solr, and I want
> to detect that there is now no leader active.
> I do e.g.
> {code}
> ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
> boolean notActive = (leader == null) ||
> !leader.containsKey(ZkStateReader.STATE_PROP) ||
> !leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
> {code}
> This does not work. It seems like changing state of a shard does it not
> changed when this Solr goes down.
> I do e.g.
> {code}
> ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
> boolean notActive = (leader == null) ||
> !leader.containsKey(ZkStateReader.STATE_PROP) ||
> !leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
> !leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
> !cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
> {code}
> Whis works.
> It seems like live-nodes of cloudState is updated when Solr goes down, but
> that some of the other info available through cloudState is not - e.g.
> getLeader().
> This might already have already been solved on 4.x branch in a revision later
> than 1355667. Then please just tell me - thanks.
> Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
