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 2013/03/13 18:30:14 UTC
[jira] [Comment Edited] (SOLR-4566) clusterstate#getSlices and
getSlicesMap should always return all slices.
[ https://issues.apache.org/jira/browse/SOLR-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601395#comment-13601395 ]
Mark Miller edited comment on SOLR-4566 at 3/13/13 5:28 PM:
------------------------------------------------------------
There really is no issue without the split shards patch though :)
That's part of what is confusing about this - it kind of seems this stuff should be part of the patch rather than pre committed. I'm not sure what the motivation of committing the shard state stuff early was.
Regardless, this issue is about cleaning up what is already committed - to me, what makes the most sense from that perspective is to improve the API, and then fix the API calls. Doing this halfway doesn't gain much, and the current state is obviously confusing as it was causing your problems with your shard splitting patch itself.
Further, even in the shard splitting issue, Shalin talks about splitting that patch out into smaller issues...
I don't know that that is necessary, but this looks like a perfect such sub issue here - lets improve the API call naming and start making the right calls? That would seem to mean that clusterstate updating code uses getSlices, shard id finding code uses getSlices, and a fair amount of other things should use getActive slices. If we get that base in here, we make the currently committed stuff sensible, and the current shard splitting code will start working against trunk without anyone needing to do the digging I did again.
was (Author: markrmiller@gmail.com):
There really is no issue without the shards patch though :)
That's part of what is confusing about this - it kind of seems this stuff should be part of the patch rather than pre committed. I'm not sure what the motivation of committing the shard state stuff early was.
Regardless, this issue is about cleaning up what is already committed - to me, what makes the most sense from that perspective is to improve the API, and then fix the API calls. Doing this halfway doesn't gain much, and the current state is obviously confusing as it was causing your problems with your shard splitting patch itself.
Further, even in the shard splitting issue, Shalin talks about splitting that patch out into smaller issues...
I don't know that that is necessary, but this looks like a perfect such sub issue here - lets improve the API call naming and start making the right calls? That would seem to mean that clusterstate updating code uses getSlices, shard id finding code uses getSlices, and a fair amount of other things should use getActive slices. If we get that base in here, we make the currently committed stuff sensible, and the current shard splitting code will start working against trunk without anyone needing to do the digging I did again.
> clusterstate#getSlices and getSlicesMap should always return all slices.
> ------------------------------------------------------------------------
>
> Key: SOLR-4566
> URL: https://issues.apache.org/jira/browse/SOLR-4566
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Fix For: 4.3, 5.0
>
> Attachments: SOLR-4566.patch
>
>
> I'm not sure I really like this getSlices vs getAllSclies - it's kind of easy to get in trouble right now I think. Some spots that we clearly want to call getAllSlices got left with getSlices. It's almost surprising that getSlices only returns active replicas - it should probably at least be called getSlicesWithActive or something more explicit. But for the first step, we should just fix the various mis calls.
> There are a couple problems around the mis calls, the most severe probably being that you can lose shards that are not active from the clusterstate.json given the right races.
--
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org