[
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: markrmil...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
